summaryrefslogtreecommitdiffstats
path: root/audio/out
Commit message (Collapse)AuthorAgeFilesLines
* audio/out/push: don't attempt to fill AO buffer when pausedwm42014-06-031-2/+3
| | | | Doing so will implicitly resume playback. Broken in commit 5929dc45.
* audio: prefer dsound over wasapiwm42014-06-011-3/+3
| | | | | ao_wasapi has too many subtle failures that were reported, but there's nobody to fix them. ao_dsound seems to be more robust; so prefer it.
* ao_alsa: make device the first sub optionwm42014-05-311-1/+1
| | | | This is more convenient.
* audio/out/push: keep some extra bufferwm42014-05-311-6/+4
| | | | | | | | | | | | | | | | | | | So the device buffer can be refilled quickly. Fixes dropouts in certain cases: if all data is moved from the soft buffer to the audio device buffer, the waiting code thinks it has to enter the mode in which it waits for new data from the decoder. This doesn't work, because the get_space() logic tries to keep the total buffer size down. get_space() will return 0 (or a very low value) because the device buffer is full, and the decoder can't refill the soft buffer. But this means if the AO buffer runs out, the device buffer can't be refilled from the soft buffer. I guess this mess happened because the code is trying to deal with both AOs with proper event handling, and AOs with arbitrary behavior. Unfortunately this increases latency, as the total buffered audio becomes larger. There are other ways to fix this again, but not today. Fixes #818.
* ao_alsa: reduce spurious wakeupswm42014-05-302-10/+18
| | | | | | Apparently this can happen. So actually only return from waiting if ALSA excplicitly signals that new output is available, or if we are woken up externally.
* audio/out/push: handle draining correctlywm42014-05-301-7/+22
| | | | | | | | | This did not flush remaining audio in the buffer correctly (in case an AO has an internal block size). So we have to make the audio feed thread to write the remaining audio, and wait until it's done. Checking the avoid_ao_wait variable should be enough to be sure that all data that can be written was written to the AO driver.
* audio: change handling of an EOF corner casewm42014-05-301-5/+9
| | | | | | This code handles buggy AOs (even if all AOs are bug-free, it's good for robustness). Move handling of it to the AO feed thread. Now this check doesn't require magic numbers and does exactly what's it supposed to do.
* ao_alsa: use poll() to wait for devicewm42014-05-301-0/+30
| | | | | This means the audio feed thread is woken up exactly at the time new data is needed, instead of using a time-based heuristic.
* audio/out/push: add a way to wait for the audio device with poll()wm42014-05-302-3/+68
| | | | Will be used for ALSA.
* audio/out/push: add mechanism for event-based waitingwm42014-05-303-76/+143
| | | | | | | | | | | | | | | | Until now, we've always calculated a timeout based on a heuristic when to refill the audio buffers. Allow AOs to do it completely event-based by providing wait and wakeup callbacks. This also shuffles around the heuristic used for other AOs, and there is a minor possibility that behavior slightly changes in real-world cases. But in general it should be much more robust now. ao_pulse.c now makes use of event-based waiting. It already did before, but the code for time-based waiting was also involved. This commit also removes one awkward artifact of the PulseAudio API out of the generic code: the callback asking for more data can be reentrant, and thus requires a separate lock for waiting (or a recursive mutex).
* audio/out: adjust documentation commentswm42014-05-301-11/+19
|
* audio/out/pull: remove race conditionswm42014-05-296-57/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were subtle and minor race conditions in the pull.c code, and AOs using it (jack, portaudio, sdl, wasapi). Attempt to remove these. There was at least a race condition in the ao_reset() implementation: mp_ring_reset() was called concurrently to the audio callback. While the ringbuffer uses atomics to allow concurrent access, the reset function wasn't concurrency-safe (and can't easily be made to). Fix this by stopping the audio callback before doing a reset. After that, we can do anything without needing synchronization. The callback is resumed when resuming playback at a later point. Don't call driver->pause, and make driver->resume and driver->reset start/stop the audio callback. In the initial state, the audio callback must be disabled. JackAudio of course is different. Maybe there is no way to suspend the audio callback without "disconnecting" it (what jack_deactivate() would do), so I'm not trying my luck, and implemented a really bad hack doing active waiting until we get the audio callback into a state where it won't interfere. Once the callback goes from AO_STATE_WAIT to NONE, we can be sure that the callback doesn't access the ringbuffer or anything else anymore. Since both sched_yield() and pthread_yield() apparently are not always available, use mp_sleep_us(1) to avoid burning CPU during active waiting. The ao_jack.c change also removes a race condition: apparently we didn't initialize _all_ ao fields before starting the audio callback. In ao_wasapi.c, I'm not sure whether reset really waits for the audio callback to return. Kovensky says it's not guaranteed, so disable the reset callback - for now the behavior of ao_wasapi.c is like with ao_jack.c, and active waiting is used to deal with the audio callback.
* ao_wasapi: simplify nAvgBytesPerSec calculationMarcoen Hirschberg2014-05-281-4/+3
| | | | | Calculate nBlockAlign seperately to reuse in the calculation of nAvgBytesPerSec.
* af_fmt2bits: change to af_fmt2bps (bytes/sample) where appropriateMarcoen Hirschberg2014-05-286-9/+9
| | | | | | In most places where af_fmt2bits is called to get the bits/sample, the result is immediately converted to bytes/sample. Avoid this by getting bytes/sample directly by introducing af_fmt2bps.
* atomics: switch to C11 stdatomic.hwm42014-05-214-35/+24
| | | | | | | | | | | | | | | | | | | | | | | | | In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-1/+1
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* audio/out: fix previous commitwm42014-05-111-9/+11
| | | | | | | | | This didn't quite work. The main issue was that get_space tries to be clever to reduce overall buffering, so it will cause the playloop to decode and queue only as much audio as is needed to refill the AO in reasonable time. Also, even if ignoring the problem, the logic of the previous commit was slightly broken. (This required a few retries, because I couldn't reproduce the issue on my own machine.)
* audio/out: avoid wakeup feedback loopwm42014-05-111-2/+7
| | | | | | | | | | | | | When the audio buffer went low, but could not be refilled yet, it could happen that the AO playback thread and the decode thread could enter a wakeup feedback loop, causing up to 100% CPU usage doing nothing. This happened because the decoder thread would wake up the AO thread when writing 0 bytes of newly decoded data, and the AO thread in reaction wakes up the decoder thread after writing 0 bytes to the AO buffer. Fix this by waking up the decoder thread only if data was actually played or queued. (This will still cause some redundant wakeups, but will eventually settle down, reducing CPU usage close to ideal.)
* audio/out: more debugging info for --dump-statswm42014-05-111-1/+5
|
* ao_coreaudio: skip unknown channel labelsStefano Pigozzi2014-05-101-0/+2
| | | | | | | | | | | | | I don't think this is really a very good idea because it is conceptually incorrect but other prominent multimedia programs use this approach (VLC and xbmc), and it seems to make the conversion more robust in certain cases. For example it has been reported, that configuring a receiver that can output 7.1 to output 5.1, will make CoreAudio report 8 channel descriptions, and the last 2 descriptions will be tagged kAudioChannelLabel_Unknown. Fixes #737
* ao_coreaudio: remove useless codeStefano Pigozzi2014-05-101-15/+0
| | | | | This code doesn't actually makes much of a difference, and the AudioUnit mostly wants layout tags anyway.
* ao_coreaudio: don't fallback to full waveextStefano Pigozzi2014-05-101-4/+5
| | | | | | The code was falling back to the full waveext chmap_sel when less than 2 channels were detected. This new code is slightly more correct since it only fills the chmap_sel with the stereo or mono chmap in the fallback case.
* ao_coreaudio: cosmetic change of loop ending conditionStefano Pigozzi2014-05-101-1/+1
|
* ao_coreaudio: print an error when channel mapping failsStefano Pigozzi2014-05-101-1/+5
|
* ao_coreaudio: use description-based channel layoutsStefano Pigozzi2014-05-103-89/+54
| | | | | | | | | | | | CoreAudio supports 3 kinds of layouts: bitmap based, tag based, and speaker description based (using either channel labels or positional data). Previously we tried to convert everything to bitmap based channel layouts, but it turns out description based ones are the most generic and there are built-in CoreAudio APIs to perform the conversion in this direction. Moreover description based layouts support waveext extensions (like SDL and SDR), and are easier to map to mp_chmaps.
* ao_coreaudio: pass layout by reference to logging functionStefano Pigozzi2014-05-101-7/+7
| | | | | Apparently passing the struct by value somehow messed with the value of some fields.
* encode: fix PTS unit mismatchwm42014-05-101-5/+5
| | | | | | This used MP_NOPTS_VALUE to compare with ffmpeg-style int64_t PTS values. This probably happened to work, because both constants use the same value.
* audio: fix the exact value that is used for the wait timewm42014-05-041-3/+2
| | | | | | | | | The comment says that it wakes up the main thread if 50% has been played, but in reality the value was 0.74/2 => 37.5%. Correct this. This probably changes little, because it's a very fuzzy heuristic in the first place. Also move down the min_wait calculation to where it's actually used.
* ao_null: fix unit mismatch with latency optionwm42014-05-041-5/+8
| | | | It's in seconds, but the code used it as sample count.
* ao_coreaudio: log even more info in verbose modeStefano Pigozzi2014-04-241-5/+27
| | | | | This logs more info that can be used for debugging purposes, in particular it prints all the AudioChannelDescription in the descriptions array.
* ao_coreaudio: add verbose output of detected channel layoutsStefano Pigozzi2014-04-231-0/+5
| | | | This can be useful for debugging purposes.
* audio: minor simplification in wait codewm42014-04-231-2/+1
|
* player: unrangle one aspect of audio EOF handlingwm42014-04-173-5/+11
| | | | | | | | | | | | | | | | | | For some reason, the buffered_audio variable was used to "cache" the ao_get_delay() result. But I can't really see any reason why this should be done, and it just seems to complicate everything. One reason might be that the value should be checked only if the AO buffers have been recently filled (as otherwise the delay could go low and trigger an accidental EOF condition), but this didn't work anyway, since buffered_audio is set from ao_get_delay() anyway at a later point if it was unset. And in both cases, the value is used _after_ filling the audio buffers anyway. Simplify it. Also, move the audio EOF condition to a separate function. (Note that ao_eof_reached() probably could/should whether the last ao_play() call had AOPLAY_FINAL_CHUNK set to avoid accidental EOF on underflows, but for now let's keep the code equivalent.)
* audio: add hack against broken pulseaudio EOF conditionwm42014-04-171-1/+16
| | | | | | | | | | | | This was reported with PulseAudio 2.1. Apparently it still has problems with reporting the correct delay. Since ao_pulse.c still has our custom get_delay implementation, there's a possibility that this is our fault, but this seems unlikely, because it's full of workarounds for issues like this. It's also possible that this problem doesn't exist on PulseAudio 5.0 anymore (I didn't explicitly retest it). The check is general and works for all push based AOs. For pull based AOs, this can't happen as pull.c implements all the logic correctly.
* audio: explicitly document audio EOF conditionwm42014-04-171-0/+5
| | | | | | This should probably be an AO function, but since the playloop still has some strange stuff (using the buffered_audio variable instead of calling ao_get_delay() directly), just leave it and make it more explicit.
* ao_null: add simulated device latency, simulate EOF problemswm42014-04-171-3/+19
| | | | | This EOF problems happen at least with PulseAudio, but since it's hard to reproduce, let ao_null optionally simulate it.
* ao: remove redundant get_delay checkwm42014-04-171-4/+0
| | | | It did nothing; the real check is in push.c.
* audio: wake up the core when audio buffer is running low (2)wm42014-04-151-2/+9
| | | | | | | | | | | | | | Same change as in e2184fcb, but this time for pull based AOs. This is slightly controversial, because it will make a fast syscall from e.g. ao_jack. And according to JackAudio developers, syscalls are evil and will destroy realtime operation. But I don't think this is an issue at all. Still avoid locking a mutex. I'm not sure what jackaudio does in the worst case - but if they set the jackaudio thread (and only this thread) to realtime, we might run into deadlock situations due to priority inversion and such. I'm not quite sure whether this can happen, but I'll readily follow the cargo cult if it makes hack happy.
* ao_pulse: use ao_need_data()wm42014-04-151-2/+2
| | | | | | | | | I'm not quite sure why ao_pulse needs this. It was broken when a thread to fill audio buffers was added to AO - the pulseaudio callback was waking up the playback thread, not the audio thread. But nobody noticed, so it can't be very important. In any case, this change makes it wake up the audio thread instead (which in turn wakes up the playback thread if needed).
* audio: wake up the core when audio buffer is running lowwm42014-04-152-15/+61
| | | | | | | | | | | | | | | | | And also add a function ao_need_data(), which AO drivers can call if their audio buffer runs low. This change intends to make it easier for the playback thread: instead of making the playback thread calculate a timeout at which the audio buffer should be refilled, make the push.c audio thread wakeup the core instead. ao_need_data() is going to be used by ao_pulse, and we need to workaround a stupid situation with pulseaudio causing a deadlock because its callback still holds the internal pulseaudio lock. For AOs that don't call ao_need_data(), the deadline is calculated by the buffer fill status and latency, as before.
* encode: add a missing \n to a log callwm42014-04-101-1/+1
|
* ao_wasapi: make code shorterwm42014-03-301-65/+36
| | | | | | | | | Also fix a format string mistake in a log call using it. I wonder if this code shouldn't use FormatMessage, but it looks kind of involved [1], so: no, thanks. [1] http://support.microsoft.com/kb/256348/en-us
* ao_lavc: set AVFrame.formatwm42014-03-161-0/+1
| | | | | Seems kind of wrong that this wasn't done, although it didn't have any bad consequences.
* encode: use new AVFrame APIwm42014-03-161-5/+3
|
* ao_dsound: remove duplicated codewm42014-03-161-17/+6
|
* af_lavrresample: remove avresample_set_channel_mapping() fallbackswm42014-03-163-3/+0
| | | | | | | This function is now always available. Also remove includes of reorder_ch.h from some AOs (these are just old relicts).
* ao: print (estimated) device buffer size on init in verbose modewm42014-03-141-1/+3
|
* ao_wasapi: Use the character set conversion functions from io.hDiogo Franco (Kovensky)2014-03-112-37/+19
| | | | | ...rather than rolling out our own. The only possible advantage is that the "custom" ones didn't use talloc.
* ao_wasapi: Implement AOCONTROL_UPDATE_STREAM_TITLEDiogo Franco (Kovensky)2014-03-113-34/+89
|
* ao_wasapi: Implement per-application mixingDiogo Franco (Kovensky)2014-03-113-16/+95
| | | | | | | | | | | | | The volume controls in mpv now affect the session's volume (the application's volume in the mixer). Since we do not request a non-persistent session, the volume and mute status persist across mpv invocations and system reboots. In exclusive mode, WASAPI doesn't have access to a mixer so the endpoint (sound card)'s master volume is modified instead. Since by definition mpv is the only thing outputting audio in exclusive mode, this causes no conflict, and ao_wasapi restores the last user-set volume when it's uninitialized.
* ao_wasapi: Move non-critical code outside of the event threadDiogo Franco (Kovensky)2014-03-114-271/+203
| | | | | | | | | | | | | | | Due to the COM Single-Threaded Apartment model, the thread owning the objects will still do all the actual method calls (in the form of message dispatches), but at least this will be COM's problem rather than having to set up several handles and adding extra code to the event thread. Since the event thread still needs to own the WASAPI handles to avoid waiting on another thread to dispatch the messages, the init and uninit code still has to run in the thread. This also removes a broken drain implementation and removes unused headers from each of the files split from the original ao_wasapi.c.
* ao_wasapi: Split into 2 filesDiogo Franco (Kovensky)2014-03-114-900/+1030
| | | | | | ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
* ao_wasapi: Initial conversion to the new pull modelDiogo Franco (Kovensky)2014-03-111-154/+73
| | | | | | | | | Gets rid of the internal ring buffer and get_buffer. Corrects an implementation error in thread_reset. There is still a possible race condition on reset, and a few refactors left to do. If feasible, the thread that handles everything WASAPI-related will be made to only handle feed events.
* ao_sdl: make sure our buffer is always larger than what SDL requestswm42014-03-101-0/+6
| | | | | | | | | Assume obtained.samples contains the number of samples the SDL audio callback will request at once. Then make sure ao.c will set the buffer size at least to 3 times that value (or more). Might help with bad SDL audio backends like ESD, which supposedly uses a 500ms buffer.
* ao_alsa: reduce default buffer sizewm42014-03-101-1/+1
| | | | | | | | | | In general, we don't need to have a large hw audio buffer size anymore, because we can quickly fill it from the soft buffer. Note that this probably doesn't change much anyway. On my system (dmix enabled), the buffer size is only 170ms, and ALSA won't give more. Even when using a hardware device the buffer size seems to be limited to 341ms.
* ao_alsa: fix return value for volume operations with spdifwm42014-03-101-1/+1
| | | | | | | | | | | This AO pretended to support volume operations when in spdif passthrough mode, but actually did nothing. This is wrong: at least the GET operations must write their argument. Signal that volume is unsupported instead. This was probably a hack to prevent insertion of volume filters or so, but it didn't work anyway, while recovering after failed volume filter insertion does work, so this is not needed at all.
* audio/out: reduce amount of audio bufferingwm42014-03-103-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | Since the addition of the AO feed thread, 200ms of latency (MIN_BUFFER) was added to all push-based AOs. This is not so nice, because even AOs with relatively small buffering (e.g. ao_alsa on my system with ~170ms of buffer size), the additional latency becomes noticable when e.g. toggling mute with softvol. Fix this by trying to keep not only 200ms minimum buffer, but also 200ms maximum buffer. In other words, never buffer beyond 200ms in total. Do this by estimating the AO's buffer fill status using get_space and the initially known AO buffer size (the get_space return value on initialization, before any audio was played). We limit the maximum amount of data written to the soft buffer so that soft buffer size and audio buffer size equal to 200ms (MIN_BUFFER). To avoid weird problems with weird AOs, we buffer beyond MIN_BUFFER if the AO's get_space requests more data than that, and as long as the soft buffer is large enough. Note that this is just a hack to improve the latency. When the audio chain gains the ability to refilter data, this won't be needed anymore, and instead we can introduce some sort of buffer replacement function in order to update data in the soft buffer.
* ao_alsa: remove unneeded initializationswm42014-03-091-6/+0
| | | | priv is 0-initialized, can_pause is always overwritten later.
* ao_alsa: check ALSA PCM state before pause and resumefoo862014-03-09