mpv/audio/out/pull.c

264 lines
8.2 KiB
C
Raw Normal View History

/*
* This file is part of mpv.
*
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
* GNU Lesser General Public License for more details.
*
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
*/
#include <stddef.h>
#include <inttypes.h>
#include <assert.h>
#include "ao.h"
#include "internal.h"
#include "audio/format.h"
#include "common/msg.h"
#include "common/common.h"
#include "input/input.h"
#include "osdep/timer.h"
#include "osdep/threads.h"
#include "osdep/atomics.h"
#include "misc/ring.h"
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.
2014-05-29 00:24:17 +00:00
/*
* Note: there is some stupid stuff in this file in order to avoid mutexes.
* This requirement is dictated by several audio APIs, at least jackaudio.
*/
enum {
AO_STATE_NONE, // idle (e.g. before playback started, or after playback
// finished, but device is open)
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.
2014-05-29 00:24:17 +00:00
AO_STATE_WAIT, // wait for callback to go into AO_STATE_NONE state
AO_STATE_PLAY, // play the buffer
AO_STATE_BUSY, // like AO_STATE_PLAY, but ao_read_data() is being called
};
#define IS_PLAYING(st) ((st) == AO_STATE_PLAY || (st) == AO_STATE_BUSY)
struct ao_pull_state {
// Be very careful with the order when accessing planes.
struct mp_ring *buffers[MP_NUM_CHANNELS];
// AO_STATE_*
atomic_int state;
// Device delay of the last written sample, in realtime.
atomic_llong end_time_us;
};
static void set_state(struct ao *ao, int new_state)
{
struct ao_pull_state *p = ao->api_priv;
while (1) {
int old = atomic_load(&p->state);
if (old == AO_STATE_BUSY) {
// A spinlock, because some audio APIs don't want us to use mutexes.
mp_sleep_us(1);
continue;
}
if (atomic_compare_exchange_strong(&p->state, &old, new_state))
break;
}
}
static int get_space(struct ao *ao)
{
struct ao_pull_state *p = ao->api_priv;
// Since the reader will read the last plane last, its free space is the
// minimum free space across all planes.
return mp_ring_available(p->buffers[ao->num_planes - 1]) / ao->sstride;
}
static int play(struct ao *ao, void **data, int samples, int flags)
{
struct ao_pull_state *p = ao->api_priv;
int write_samples = get_space(ao);
write_samples = MPMIN(write_samples, samples);
// Write starting from the last plane - this way, the first plane will
// always contain the minimum amount of data readable across all planes
// (assumes the reader starts with the first plane).
int write_bytes = write_samples * ao->sstride;
for (int n = ao->num_planes - 1; n >= 0; n--) {
int r = mp_ring_write(p->buffers[n], data[n], write_bytes);
assert(r == write_bytes);
}
int state = atomic_load(&p->state);
if (!IS_PLAYING(state)) {
set_state(ao, AO_STATE_PLAY);
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.
2014-05-29 00:24:17 +00:00
ao->driver->resume(ao);
}
return write_samples;
}
// Read the given amount of samples in the user-provided data buffer. Returns
// the number of samples copied. If there is not enough data (buffer underrun
// or EOF), return the number of samples that could be copied, and fill the
// rest of the user-provided buffer with silence.
// This basically assumes that the audio device doesn't care about underruns.
// If this is called in paused mode, it will always return 0.
// The caller should set out_time_us to the expected delay until the last sample
// reaches the speakers, in microseconds, using mp_time_us() as reference.
int ao_read_data(struct ao *ao, void **data, int samples, int64_t out_time_us)
{
assert(ao->api == &ao_api_pull);
struct ao_pull_state *p = ao->api_priv;
int full_bytes = samples * ao->sstride;
bool need_wakeup = false;
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.
2014-05-29 00:24:17 +00:00
int bytes = 0;
// Play silence in states other than AO_STATE_PLAY.
if (!atomic_compare_exchange_strong(&p->state, &(int){AO_STATE_PLAY},
AO_STATE_BUSY))
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.
2014-05-29 00:24:17 +00:00
goto end;
// Since the writer will write the first plane last, its buffered amount
// of data is the minimum amount across all planes.
int buffered_bytes = mp_ring_buffered(p->buffers[0]);
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.
2014-05-29 00:24:17 +00:00
bytes = MPMIN(buffered_bytes, full_bytes);
if (bytes > 0)
atomic_store(&p->end_time_us, out_time_us);
for (int n = 0; n < ao->num_planes; n++) {
int r = mp_ring_read(p->buffers[n], data[n], bytes);
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.
2014-05-29 00:24:17 +00:00
bytes = MPMIN(bytes, r);
}
// Half of the buffer played -> request more.
need_wakeup = buffered_bytes - bytes <= mp_ring_size(p->buffers[0]) / 2;
// Should never fail.
atomic_compare_exchange_strong(&p->state, &(int){AO_STATE_BUSY}, AO_STATE_PLAY);
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.
2014-05-29 00:24:17 +00:00
end:
if (need_wakeup)
mp_input_wakeup_nolock(ao->input_ctx);
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.
2014-05-29 00:24:17 +00:00
// pad with silence (underflow/paused/eof)
for (int n = 0; n < ao->num_planes; n++)
af_fill_silence((char *)data[n] + bytes, full_bytes - bytes, ao->format);
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.
2014-05-29 00:24:17 +00:00
return bytes / ao->sstride;
}
static int control(struct ao *ao, enum aocontrol cmd, void *arg)
{
if (ao->driver->control)
return ao->driver->control(ao, cmd, arg);
return CONTROL_UNKNOWN;
}
// Return size of the buffered data in seconds. Can include the device latency.
// Basically, this returns how much data there is still to play, and how long
// it takes until the last sample in the buffer reaches the speakers. This is
// used for audio/video synchronization, so it's very important to implement
// this correctly.
static double get_delay(struct ao *ao)
{
struct ao_pull_state *p = ao->api_priv;
int64_t end = atomic_load(&p->end_time_us);
int64_t now = mp_time_us();
double driver_delay = MPMAX(0, (end - now) / (1000.0 * 1000.0));
return mp_ring_buffered(p->buffers[0]) / (double)ao->bps + driver_delay;
}
static void reset(struct ao *ao)
{
struct ao_pull_state *p = ao->api_priv;
if (ao->driver->reset)
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.
2014-05-29 00:24:17 +00:00
ao->driver->reset(ao); // assumes the audio callback thread is stopped
set_state(ao, AO_STATE_NONE);
for (int n = 0; n < ao->num_planes; n++)
mp_ring_reset(p->buffers[n]);
atomic_store(&p->end_time_us, 0);
}
static void pause(struct ao *ao)
{
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.
2014-05-29 00:24:17 +00:00
if (ao->driver->reset)
ao->driver->reset(ao);
set_state(ao, AO_STATE_NONE);
}
static void resume(struct ao *ao)
{
set_state(ao, AO_STATE_PLAY);
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.
2014-05-29 00:24:17 +00:00
ao->driver->resume(ao);
}
static bool get_eof(struct ao *ao)
{
struct ao_pull_state *p = ao->api_priv;
// For simplicity, ignore the latency. Otherwise, we would have to run an
// extra thread to time it.
return mp_ring_buffered(p->buffers[0]) == 0;
}
static void drain(struct ao *ao)
{
struct ao_pull_state *p = ao->api_priv;
int state = atomic_load(&p->state);
if (IS_PLAYING(state)) {
// Wait for lower bound.
mp_sleep_us(mp_ring_buffered(p->buffers[0]) / (double)ao->bps * 1e6);
// And then poll for actual end. (Unfortunately, this code considers
// audio APIs which do not want you to use mutexes in the audio
// callback, and an extra semaphore would require slightly more effort.)
// Limit to arbitrary ~250ms max. waiting for robustness.
int64_t max = mp_time_us() + 250000;
while (mp_time_us() < max && !get_eof(ao))
mp_sleep_us(1);
}
reset(ao);
}
static void uninit(struct ao *ao)
{
ao->driver->uninit(ao);
}
static int init(struct ao *ao)
{
struct ao_pull_state *p = ao->api_priv;
for (int n = 0; n < ao->num_planes; n++)
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.
2014-05-29 00:24:17 +00:00
p->buffers[n] = mp_ring_new(ao, ao->buffer * ao->sstride);
atomic_store(&p->state, AO_STATE_NONE);
assert(ao->driver->resume);
return 0;
}
const struct ao_driver ao_api_pull = {
.init = init,
.control = control,
.uninit = uninit,
.drain = drain,
.reset = reset,
.get_space = get_space,
.play = play,
.get_delay = get_delay,
.get_eof = get_eof,
.pause = pause,
.resume = resume,
.priv_size = sizeof(struct ao_pull_state),
};