summaryrefslogtreecommitdiffstats
path: root/audio/out/internal.h
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-05-29 02:24:17 +0200
committerwm4 <wm4@nowhere>2014-05-29 02:24:17 +0200
commitc36faf8c499c64548ea3920aadb8a4b43aa0f5a0 (patch)
treefc0437bb02806dda15144245fceda6c500a1bf13 /audio/out/internal.h
parent690ea07b7a8a034303fa2b42a8c6854f9ba46f7f (diff)
downloadmpv-c36faf8c499c64548ea3920aadb8a4b43aa0f5a0.tar.bz2
mpv-c36faf8c499c64548ea3920aadb8a4b43aa0f5a0.tar.xz
audio/out/pull: remove race conditions
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.
Diffstat (limited to 'audio/out/internal.h')
-rw-r--r--audio/out/internal.h7
1 files changed, 7 insertions, 0 deletions
diff --git a/audio/out/internal.h b/audio/out/internal.h
index cc3abb14f5..2f2fbd307b 100644
--- a/audio/out/internal.h
+++ b/audio/out/internal.h
@@ -86,6 +86,9 @@ extern const struct ao_driver ao_api_pull;
* get_delay
* pause
* resume
+ * Optional:
+ * control
+ * drain
* b) ->play must be NULL. The driver can start the audio API in init(). The
* audio API in turn will start a thread and call a callback provided by the
* driver. That callback calls ao_read_data() to get audio data. Most
@@ -94,6 +97,10 @@ extern const struct ao_driver ao_api_pull;
* Mandatory:
* init
* uninit
+ * resume (starts the audio callback)
+ * Also, the following optional callbacks can be provided:
+ * reset (stops the audio callback, resume() restarts it)
+ * control
*/
struct ao_driver {
// If true, use with encoding only.