summaryrefslogtreecommitdiffstats
path: root/audio/out
Commit message (Collapse)AuthorAgeFilesLines
* ao/wasapi: only retry resizing the buffer onceKevin Mitchell2014-11-181-8/+10
| | | | | | like the MSDN example: http://msdn.microsoft.com/en-us/library/windows/desktop/dd370875%28v=vs.85%29.aspx
* ao/wasapi: keep bufferPeriod in sync on retryKevin Mitchell2014-11-181-1/+4
| | | | | Without this, the retry will fail if they are not equal or bufferPeriod is zero.
* ao/wasapi: refix printf warning for both cygwin and msysKevin Mitchell2014-11-181-2/+2
| | | | a cast to (unsigned) should do "the right thing".
* ao/wasapi: periodicity in shared mode must be zeroKevin Mitchell2014-11-181-3/+6
| | | | | | IAudioClient::Initialize hnsPeriodicity argument is nonzero only for exclusive mode http://msdn.microsoft.com/en-us/library/windows/desktop/dd370805%28v=vs.85%29.aspx
* ao/wasapi: increase buffer size to 50 msKevin Mitchell2014-11-183-16/+26
| | | | | Before it was the default device period, which was too small causing glitches on on entering/exiting fullscreen.
* audio/out: always log retrieved audio device sizewm42014-11-181-2/+2
|
* ao/wasapi: fix leaked marshaled interface streamsJonathan Yong2014-11-181-0/+9
| | | | Signed-off-by: Kevin Mitchell <kevmitch@gmail.com>
* ao/wasapi: Don't free stuff the thread may still be using on timeoutKevin Mitchell2014-11-171-1/+3
| | | | | In the unlikely event of a timeout waiting for the audio thread to return, don't free stuff that it may still be using.
* ao/wasapi: also free the threadLoop handle on uninitKevin Mitchell2014-11-171-0/+1
| | | | http://msdn.microsoft.com/en-us/library/windows/desktop/ms682453%28v=vs.85%29.aspx
* ao/wasapi: fix leaked event handlesKevin Mitchell2014-11-171-6/+5
|
* ao/wasapi: fix race condition in uninit on failure.Kevin Mitchell2014-11-171-2/+1
| | | | | | | | | When the audio thread fails to properly init, it signals failure to the main thread, AND THEN starts to clean up. For this to work, ao_init callback must not return until the thread's cleanup is finished. This is correctly handled in the ao_uninit callback by waiting for the thread to exit, so just call that to clean up the main thread. I have no idea why I didn't do this in the first place.
* ao/wasapi: silence format string warningsJames Ross-Gowan2014-11-182-2/+2
|
* ao_alsa: check for EAGAIN toowm42014-11-171-1/+1
| | | | | | | Simply retry on EAGAIN. I've seen this in several other projects; it might be just cargo-culting though.
* audio/out: switch back to wasapi as default on win32wm42014-11-171-3/+3
| | | | | | dsound was set as default, because there were some hard to fix problems with wasapi. These problems were probably fixed now, so let's try with wasapi as default again.
* ao/wasapi: request ao reload on thread_feed failuresKevin Mitchell2014-11-171-0/+2
| | | | | | Even with change notifications, there are still (rare) cases when the feed thread gets AUDCLIENT_DEVICE_INVALIDATED. So handle failures in thread_feed by requesting ao_reload.
* ao/wasapi: add retry loop on AUDCLNT_E_DEVICE_IN_USEKevin Mitchell2014-11-171-0/+12
| | | | this works around reinitializing too fast on device property changes
* ao/wasapi: request reset on appropriate eventsKevin Mitchell2014-11-174-56/+117
| | | | | | | | on changes to PKEY_AudioEngine_DeviceFormat, device status, and default device. call ao_reload directly in the change_notify "methods". this requires keeping a device enumerator around for the duration of execution, rather than just for initially querying devices
* ao/wasapi: add convenience functions for change notifiyKevin Mitchell2014-11-171-0/+49
|
* ao/wasapi: new wasapi device monitoring interfaceJonathan Yong2014-11-172-0/+179
| | | | | | | | | | | Implement skeleton IMMNotificationClient to watch for changes in the sound device. This will make recovery possible from changes shared mode sample rate, bit depth, "enhancements"/effects and even graceful device removal. http://msdn.microsoft.com/en-us/library/windows/desktop/dd371417%28v=vs.85%29.aspx Signed-off-by: Kevin Mitchell <kevmitch@gmail.com>
* ao/wasapi: look for "multimedia" default device instead of "console"Kevin Mitchell2014-11-171-2/+2
| | | | | | console is more for system notifications / voice command, mpv is most certainly multimedia http://msdn.microsoft.com/en-us/library/windows/desktop/dd370842%28v=vs.85%29.aspx
* ao/wasapi: put loading of default device in it's own functionKevin Mitchell2014-11-171-17/+30
|
* ao/wasapi: fix possible null dereference of pDeviceKevin Mitchell2014-11-171-0/+1
| | | | | | IMMDeviceEnumerator::GetDefaultAudioEndpoint may set pDevice to null on failure. http://msdn.microsoft.com/en-us/library/windows/desktop/dd371401%28v=vs.85%29.aspx
* ao/wasapi: tidy up better on failureKevin Mitchell2014-11-173-14/+26
| | | | | | | Before, failures, particularly in the thread loop init, could lead to a bad state for the duration of mpvs execution. Make sure that everything that was initialized gets properly and safely uninitialized.
* ao/wasapi: improve error messages and add more debug statementsKevin Mitchell2014-11-174-98/+140
| | | | | | also enforce more consistency in the exit codes and error handling thanks to Jonathan Yong <10walls@gmail.com>
* ao/wasapi: make calling of thread_init consistent with thread_uninitKevin Mitchell2014-11-173-3/+5
|
* ao/wasapi: reenable the reset functionKevin Mitchell2014-11-171-1/+1
| | | | | | the race condition that necessitated disabling this was fixed in e4403523131a69a92a8418bb3714090a408680c7
* ao/wasapi: fix leaked deviceIDJonathan Yong2014-11-171-0/+1
|
* ao_lavc, vo_lavc: Fix crashes in case of multiple init attempts.Rudolf Polzer2014-11-121-0/+8
| | | | | | | | | | | | When initialization failed, vo_lavc may cause an irrecoverable state in the ffmpeg-related structs. Therefore, we reject additional initialization attempts at least until we know a better way to clean up the mess. ao_lavc currently cannot be initialized more than once, yet it's good to do consistent changes there as well. Also, clean up uninit-after-failure handling to be less spammy.
* audio/out/pull: avoid deadlock if audio callback stopswm42014-11-091-26/+40
| | | | | | | | | | | | | | | | | | | | | | | | If the audio callback suddenly stops, and the AO provides no "reset" callback, then reset() could deadlock by waiting on the audio callback forever. The waiting was needed to enter a consistent state, where the audio callback guarantees it won't access the ringbuffer. This in turn is needed because mp_ring_reset() is not concurrency-safe. This active waiting is unavoidable. But the way it was implemented, the audio callback had to call ao_read_data() at least once when reset() is called. Fix this by making ao_read_data() set a flag upon entering and leaving, which basically turns p->state into some sort of spinlock. The audio callback actually never needs to spin, because there are only 2 states: playing audio, or playing silence. This might be a bit surprising, because usually atomic_compare_exchange_strong() requires a retry-loop idiom for correct operation. This commit is needed because ao_wasapi can (or will in the future) randomly stop the audio callback in certain corner cases. Then the player would hang forever in reset().
* audio/out: consistently use double return type for get_delaywm42014-11-0912-27/+25
| | | | | ao_get_delay() returns double, but the get_delay callback still returned float.
* audio/out: make ao_request_reload() idempotentwm42014-11-093-9/+25
| | | | | | | | | | This is what you would expect. Before this commit, each ao_request_reload() call would just queue a reload command, and then recreate the AO for the number of times the function was called. Instead of sending a command, introduce some sort of event retrieval mechanism. At least for the reload case, use atomics, because we're too lazy to setup an extra mutex.
* audio: add --audio-client-name optionwm42014-11-073-5/+7
| | | | | | The main need I see for this is with libmpv - it would be confusing if some application showed up as "mpv" on whateverthehell PulseAudio uses it for (generally it does show up on various PA GUI tools).
* ao_oss: wait for events with poll()wm42014-11-061-0/+13
| | | | | | | | | | The intention is to avoid using the timeout-based fallback. There's some minor hope that this will help with OpenBSD (see #1239), although it probably won't. Some chance that this will cause trouble with obscure OSS implementations or emulations.
* audio/out/push: when using audio wait fallback, recheck conditionwm42014-11-061-1/+2
| | | | | | | | | | | If calling ao->driver->wait() fails, we need to fallback to timeout- based waiting. But it could be that at this point, the mutex was already released (and then re-acquired). So we need to recheck the condition in order to avoid missed wakeups. This probably wasn't an actually occurring problem, but still could cause a small race-condition window if the dynamic fallback is actually used.
* ao_alsa: don't make snd_pcm_hw_params_set_buffer_time_near() error fatalwm42014-10-311-1/+7
| | | | | | | | | | | | | Apparently this can "sometimes" return an error. In my opinion, this should never return an error: neither the semantics of the function, nor the ALSA documentation or ALSA sample code seem to indicate that a failure is to be expected. I'm not perfectly sure about this though (I blame ALSA being a weird, big, underdocumented API). Since it causes problems for some users, and since there is really no reason why we should abort on such an error, turn it into a warning. Fixes #1231.
* coreaudio: only list output devicesStefano Pigozzi2014-10-281-0/+12
|
* audio: add command/function to reload audio outputwm42014-10-272-0/+10
| | | | | Anticipated use: simple solution for dealing with audio APIs which request configuration changes via events.
* ao_alsa: move parameter append code to a functionwm42014-10-231-16/+27
| | | | | Why not. (I thought I needed this, but my other experiments failed. So this is merely a minor cleanup.)
* rename ao_coreaudio_device.c -> ao_coreaudio_exclusive.cStefano Pigozzi2014-10-231-0/+0
| | | | This is so that the source file name matches the AO name
* coreaudio: redirect IEC61937 to coreaudio_exclusiveStefano Pigozzi2014-10-232-1/+7
|
* audio/out: add redirection-on-init mechanismwm42014-10-222-14/+47
| | | | | Looks like this will help us with making --audio-device and spdif work as expected on OSX. To be used ina following commit.
* audio/out: missing error checkwm42014-10-221-0/+2
| | | | Oops.
* audio/out: don't add special devices to --audio-device listwm42014-10-221-2/+2
| | | | | | | | | | | | | | | | | | Since the list associated with --audio-device is supposed to enable simple user-selection, it doesn't make much sense to include overly special things like ao_pcm or ao_null in the list. Specifically, ao_pcm is harmful, because it will just dump all audio to a file named audiodump.wav in the current working directory. The user can't choose the filename (it can be customized, but not through this option), and the working directory might be essentially random, especially if this is used from a GUI. Exclude "strange" entries. We reuse the fact that there's already a simple list ordered by auto-probe priority in order to avoid having to add an additional flag. This is also why coreaudio_exclusive was moved above ao_null: ao_null ends auto-probing and marks the start of "special" outputs, which don't show up on the device, but we want coreaudio_exclusive to be selectable (I think).
* audio/out: include coreaudio_exclusive in auto-probingwm42014-10-221-3/+3
| | | | | | | Move it above ao_null, so that it can be selected during auto-probing (even if it's only last). I see no reason why it should not be included, and it makes the following commit slightly more elegant. (See explanations there.)
* Set thread name for debuggingwm42014-10-191-0/+1
| | | | | | | | | | Especially with other components (libavcodec, OSX stuff), the thread list can get quite populated. Setting the thread name helps when debugging. Since this is not portable, we check the OS variants in waf configure. old-configure just gets a special-case for glibc, since doing a full check here would probably be a waste of effort.
* audio: quote devices in --audio-device=helpwm42014-10-191-1/+1
| | | | | The output is a bit confusing. Quoting the device name probably helps a little bit; also add minimal explanations to the manpage.
* audio/out/push: reset projected EOF time on new datawm42014-10-141-1/+4
| | | | | Seems like this could theoretically happen in low buffer situations, but I haven't spotted this behavior in the wild.
* ao_wasapi: implement device listingwm42014-10-133-10/+32
|
* ao_dsound: implement device listingwm42014-10-131-20/+86
|
* ao_portaudio: implement device listingwm42014-10-131-2/+24
|
* ao_openal: implement device listingwm42014-10-131-1/+16
|
* audio/out: add "auto" pseudo-devicewm42014-10-131-1/+3
| | | | | Also, don't set an empty string for the fallback device if an AO doesn't list any devices.
* coreaudio: use the new device selection APIStefano Pigozzi2014-10-124-54/+28
| | | | | The CoreAudio API is built around device IDs so we store the integer as string and read it back.
* audio: don't list encoder AO with --audio-device=helpwm42014-10-101-0/+2
|
* ao_pulse: implement AO device listing APIwm42014-10-101-1/+38
| | | | | | | | | | | | | | | | While conceptually this sink stuff in PulseAudio does just the right thing, actually listing the sinks is unbelievable complicated. Not only is the idea that listing them should happen asynchronously completely bullshit (who the fuck runs the PulseAudio server on a separate computer), but the way this is done is full of bullshit too. Why separate callbacks for each device? Why this obtuse mainloop shit? Especially the mainloop shit makes it actively worse than doing things manually with pthread primitives, and the reason for that (different mainloop implementations for GUIs?) is laughable too. It's like they chose the most complicated API possible just because they attempted to "abstract" basic mechanisms in order to handle "everything". While I don't claim to design the best APIs, this API is fucking terrible without any excuse. (End of rant.)
* ao_pulse: move setup code to separate functionwm42014-10-101-23/+48
| | | | | | | All the dumb crap in pa_init_boilerplate() is needed to talk to the audio server at all. Might also fix some subtle bugs in the init code (which is strange, because the original file was contributed by the devil himself).
* audio: change internal device listing APIwm42014-10-104-27/+53
| | | | | Now we run ao_driver->list_devs on a dummy AO instance, which will probably confuse everyone. This is done for the sake of PulseAudio.
* Add some missing "const"swm42014-10-102-3/+5
| | | | | | | The one in msg.c was mistakenly removed with commit e99a37f6. I didn't actually test the change in ao_sndio.c (but obviously "ap" shouldn't be static).
* audio/out/push: make draining slightly more robustwm42014-10-101-1/+1
| | | | | | | | Don't wait after the audio thread has pushed the remaining audio to the AO. Avoids hard hangs if the heuristic fails completely (could still happen if get_delay returns absurd values). CC: @mpv-player/stable
* audio/out/push: fix EOF heuristicwm42014-10-102-23/+14
| | | | | | | | | | | | | Since the internal AO driver API has no proper way to determine EOF, we need to guess by querying get_delay. But some AOs (e.g. ao_pulse with no-latency-hacks set) may never reach 0, maybe because they naively add the latency to the buffer level. In this case our heuristic can break. Fix by always using the delay to estimate the EOF time. It's not even that important - it's mostly used to avoid blocking draining. So this should be ok. CC: @mpv-player/stable (maybe)
* fix -Wvisibility warnings with clangStefano Pigozzi2014-10-091-2/+1
| | | | Now everything compiles with no warnings! yay!
* ao_alsa: implement device listing & selectionwm42014-10-091-0/+27
| | | | | | | Unfortunately, ALSA is particularly bad with this, because mpv has to add all sorts of magic crap to the device name to make things work. The device selection overrides this, so explicitly selecting devices will most likely break your audio. This has yet to be solved.
* audio: add device selection & listing with --audio-devicewm42014-10-093-6/+104
| | | | | | | Not sure how good of an idea this is. This commit doesn't add support for this to any AO yet; the AO implementations will follow later.
* ao_pulse: don't use pa_format_info_to_sample_spec()wm42014-10-061-9/+4
| | | | | | | | | | | This function is available starting with PulseAudio 2.0, while we only require 1.0. This broke compilation on Ubuntu 12.04.5 LTS. Use our own function to calculate the buffer size, which is actually simpler and needs slightly less code. Hopefully fixes #1154. CC: @mpv-player/stable
* audio/out/push: fix some AOs freezing on exitwm42014-10-051-1/+1
| | | | Caused by a dumb deadlock.
* audio/out/push: make draining more robustwm42014-10-051-20/+15
| | | | | | It was more complicated than it had to be: the audio thread already determines whether audio has ended, so we can use that. Remove the separate logic for draining.
* audio/out/push: limit fallback sleep time to reasonable limitswm42014-10-051-2/+4
|
* ao_pulse: change suspend circumvention logicwm42014-10-041-1/+6
| | | | | | | | | | | | | | Commit 957097 attempted to use PA_STREAM_FAIL_ON_SUSPEND to make ao_pulse exit if the stream was started suspended. Unfortunately, PA_STREAM_FAIL_ON_SUSPEND is active even during playback. If you pause mpv, pulseaudio will close the actual audio device after a while (or something like this), and unpausing won't work. Instead, it will spam "Entity killed" error messages. Undo this change and check for suspended audio manually during init. CC: @mpv-player/stable
* ao_pulse: refuse to start suspendedwm42014-10-031-1/+1
| | | | | | | | | | | | Sometimes, ao_pulse starts in suspended mode, which means playback is essentially paused in pulseaudio. This gives the impression that mpv is hanging, since it times video against the audio playback progress, and audio never makes progress in this state. I'm not sure if this will help - possibly it does with mixed pulseaudio/alsa setups. However, if the alsa setup has the pulseaudio plugin, alsa will hang too. But there's still a chance we get less blame for pulseaudio messes.
* audio/out/push: clean up properly on init errorwm42014-09-271-9/+16
| | |