RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-13 18:36:09 +00:00
Code Issues Releases Wiki Activity
81d125efd8
mpv/audio/out/internal.h

214 lines
8.4 KiB
C
Raw Normal View History

audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
/*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* This file is part of mpv.
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* mpv is free software; you can redistribute it and/or modify
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* mpv is distributed in the hope that it will be useful,
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* with mpv. If not, see <http://www.gnu.org/licenses/>.
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
*/
#ifndef MP_AO_INTERNAL_H_
#define MP_AO_INTERNAL_H_
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
#include <stdbool.h>
audio/out/push: add mechanism for event-based waiting 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).
2014-05-29 21:56:48 +00:00
#include <pthread.h>
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
osdep: rename atomics.h to atomic.h The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
2016-09-07 09:26:25 +00:00
#include "osdep/atomic.h"
fix -Wvisibility warnings with clang Now everything compiles with no warnings! yay!
2014-10-09 20:21:24 +00:00
#include "audio/out/ao.h"
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
/* global data used by ao.c and ao drivers */
struct ao {
int samplerate;
struct mp_chmap channels;
int format; // one of AF_FORMAT_...
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
int bps; // bytes per second (per plane)
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
int sstride; // size of a sample on each plane
// (format_size*num_channels/num_planes)
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
int num_planes;
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
bool probing; // if true, don't fail loudly on init
bool untimed; // don't assume realtime playback
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
int device_buffer; // device buffer in samples (guessed by
// common init code if not set by driver)
const struct ao_driver *api; // entrypoints to the wrapper (push.c/pull.c)
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
const struct ao_driver *driver;
void *priv;
ao_alsa: change sub-options to global options Same deal as with vo_opengl. Also edit the outdated information about multichannel output a little.
2016-09-02 18:07:25 +00:00
struct mpv_global *global;
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
struct encode_lavc_context *encode_lavc_ctx;
player, ao, vo: don't call mp_input_wakeup() directly Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
2016-09-16 12:23:54 +00:00
void (*wakeup_cb)(void *ctx);
void *wakeup_ctx;
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
struct mp_log *log; // Using e.g. "[ao/coreaudio]" as prefix
audio: use --audio-channels=auto behavior, except on ALSA This commit adds an --audio-channel=auto-safe mode, and makes it the default. This mode behaves like "auto" with most AOs, except with ao_alsa. The intention is to allow multichannel output by default on sane APIs. ALSA is not sane as in it's so low level that it will e.g. configure any layout over HDMI, even if the connected A/V receiver does not support it. The HDMI fuckup is of course not ALSA's fault, but other audio APIs normally isolate applications from dealing with this and require the user to globally configure the correct output layout. This will help with other AOs too. ao_lavc (encoding) is changed to the new semantics as well, because it used to force stereo (perhaps because encoding mode is supposed to produce safe files for crap devices?). Exclusive mode output on Windows might need to be adjusted accordingly, as it grants the same kind of low level access as ALSA (requires more research). In addition to the things mentioned above, the --audio-channels option is extended to accept a set of channel layouts. This is supposed to be the correct way to configure mpv ALSA multichannel output. You need to put a list of channel layouts that your A/V receiver supports.
2016-08-04 18:49:20 +00:00
int init_flags; // AO_INIT_* flags
player: add --audio-stream-silence Completely insane that this has to be done. Crap for compensating HDMI crap.
2016-08-09 14:22:06 +00:00
bool stream_silence; // if audio inactive, just play silence
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
audio: add device selection & listing with --audio-device 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.
2014-10-09 19:21:31 +00:00
// The device as selected by the user, usually using ao_device_desc.name
// from an entry from the list returned by driver->list_devices. If the
// default device should be used, this is set to NULL.
char *device;
command: add property returning detected audio device This can be useful to adjust some other audio related properties at runtime depending on the audio device being used.
2015-02-02 22:01:11 +00:00
// Device actually chosen by the AO
char *detected_device;
audio: add --audio-client-name option 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).
2014-11-07 14:54:35 +00:00
// Application name to report to the audio API.
char *client_name;
audio/out: add redirection-on-init mechanism Looks like this will help us with making --audio-device and spdif work as expected on OSX. To be used ina following commit.
2014-10-22 15:12:08 +00:00
// Used during init: if init fails, redirect to this ao
char *redirect;
audio: add device change notification for hotplugging Not very important for the command line player; but GUI applications will want to know about this. This only adds the internal API; support for specific audio outputs comes later. This reuses the ao struct as context for the hotplug event listener, similar to how the "old" device listing API did. This is probably a bit unclean and confusing. One argument got reusing it is that otherwise rewriting parts of ao_pulse would be required (because the PulseAudio API requires so damn much boilerplate). Another is that --ao-defaults is applied to the hotplug dummy ao struct, which automatically applies such defaults even to the hotplug context. Notification works through the property observation mechanism in the client API. The notification chain is a bit complicated: the AO notifies the player, which in turn notifies the clients, which in turn will actually retrieve the device list. (It still has the advantage that it's slightly cleaner, since the AO stuff doesn't need to know about client API issues.) The weird handling of atomic flags in ao.c is because we still don't require real atomics from the compiler. Otherwise we'd just use atomic bitwise operations.
2015-02-12 15:53:56 +00:00
// Internal events (use ao_request_reload(), ao_hotplug_event())
ao: make better use of atomics The main reason for this was compatibility; but some associated problems have been solved in the previous commit.
2015-05-11 21:27:41 +00:00
atomic_int events_;
audio/out: make ao_request_reload() idempotent 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.
2014-11-09 08:58:44 +00:00
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
int buffer;
audio: make buffer size configurable Really only for testing.
2014-09-04 21:48:27 +00:00
double def_buffer;
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
void *api_priv;
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
};
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
extern const struct ao_driver ao_api_push;
extern const struct ao_driver ao_api_pull;
/* Note:
*
* In general, there are two types of audio drivers:
* a) push based (the user queues data that should be played)
* b) pull callback based (the audio API calls a callback to get audio)
*
* The ao.c code can handle both. It basically implements two audio paths
* and provides a uniform API for them. If ao_driver->play is NULL, it assumes
* that the driver uses a callback based audio API, otherwise push based.
*
* Requirements:
audio/out: adjust documentation comments
2014-05-29 21:56:44 +00:00
* a) ->play is called to queue audio. push.c creates a thread to regularly
* refill audio device buffers with ->play, but all driver functions are
* always called under an exclusive lock.
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
* Mandatory:
* init
* uninit
* reset
* get_space
* play
* get_delay
* pause
* resume
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
* Optional:
* control
* drain
audio/out/push: add mechanism for event-based waiting 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).
2014-05-29 21:56:48 +00:00
* wait
* wakeup
audio/out: adjust documentation comments
2014-05-29 21:56:44 +00:00
* b) ->play must be NULL. ->resume must be provided, and should make the
* audio API start calling the audio callback. Your audio callback should
* in turn call ao_read_data() to get audio data. Most functions are
* optional and will be emulated if missing (e.g. pausing is emulated as
* silence). ->get_delay and ->get_space are never called.
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
* Mandatory:
* init
* uninit
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
* resume (starts the audio callback)
* Also, the following optional callbacks can be provided:
* reset (stops the audio callback, resume() restarts it)
* control
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
*/
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
struct ao_driver {
// If true, use with encoding only.
bool encode;
// Name used for --ao.
const char *name;
// Description shown with --ao=help.
const char *description;
// Init the device using ao->format/ao->channels/ao->samplerate. If the
// device doesn't accept these parameters, you can attempt to negotiate
// fallback parameters, and set the ao format fields accordingly.
int (*init)(struct ao *ao);
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
// Optional. See ao_control() etc. in ao.c
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
int (*control)(struct ao *ao, enum aocontrol cmd, void *arg);
audio/out: make draining a separate operation Until now, this was always conflated with uninit. This was ugly, and also many AOs emulated this manually (or just ignored it). Make draining an explicit operation, so AOs which support it can provide it, and for all others generic code will emulate it. For ao_wasapi, we keep it simple and basically disable the internal draining implementation (maybe it should be restored later). Tested on Linux only.
2014-03-08 23:49:39 +00:00
void (*uninit)(struct ao *ao);
audio/out: adjust documentation comments
2014-05-29 21:56:44 +00:00
// push based: see ao_reset()
// pull based: stop the audio callback
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
void (*reset)(struct ao*ao);
audio/out: adjust documentation comments
2014-05-29 21:56:44 +00:00
// push based: see ao_pause()
void (*pause)(struct ao *ao);
// push based: see ao_resume()
// pull based: start the audio callback
void (*resume)(struct ao *ao);
// push based: see ao_play()
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
int (*get_space)(struct ao *ao);
audio/out: adjust documentation comments
2014-05-29 21:56:44 +00:00
// push based: see ao_play()
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
int (*play)(struct ao *ao, void **data, int samples, int flags);
audio/out: adjust documentation comments
2014-05-29 21:56:44 +00:00
// push based: see ao_get_delay()
audio/out: consistently use double return type for get_delay ao_get_delay() returns double, but the get_delay callback still returned float.
2014-11-09 10:45:04 +00:00
double (*get_delay)(struct ao *ao);
audio/out: adjust documentation comments
2014-05-29 21:56:44 +00:00
// push based: block until all queued audio is played (optional)
audio/out: make draining a separate operation Until now, this was always conflated with uninit. This was ugly, and also many AOs emulated this manually (or just ignored it). Make draining an explicit operation, so AOs which support it can provide it, and for all others generic code will emulate it. For ao_wasapi, we keep it simple and basically disable the internal draining implementation (maybe it should be restored later). Tested on Linux only.
2014-03-08 23:49:39 +00:00
void (*drain)(struct ao *ao);
audio/out: make EOF handling properly event-based With --gapless-audio=no, changing from one file to the next apparently made it hang, until the player was woken up by unrelated events like input. The reason was that the AO doesn't notify the player of EOF properly. the played was querying ao_eof_reached(), and then just went to sleep, without anything waking it up. Make it event-based: the AO wakes up the playloop if the EOF state changes. We could have fixed this in a simpler way by synchronously draining the AO in these cases. But I think proper event handling is preferable. Fixes: #1069 CC: @mpv-player/stable (perhaps)
2014-09-05 20:21:06 +00:00
// Optional. Return true if audio has stopped in any way.
bool (*get_eof)(struct ao *ao);
audio/out/push: add mechanism for event-based waiting 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).
2014-05-29 21:56:48 +00:00
// Wait until the audio buffer needs to be refilled. The lock is the
// internal mutex usually protecting the internal AO state (and used to
// protect driver calls), and must be temporarily unlocked while waiting.
// ->wakeup will be called (with lock held) if the wait should be canceled.
// Returns 0 on success, -1 on error.
// Optional; if this is not provided, generic code using audio timing is
// used to estimate when the AO needs to be refilled.
// Warning: it's only called if the feed thread truly needs to know when
// the audio thread takes data again. Often, it will just copy
// the complete soft-buffer to the AO, and then wait for the
// decoder instead. Don't do necessary work in this callback.
int (*wait)(struct ao *ao, pthread_mutex_t *lock);
// In combination with wait(). Lock may or may not be held.
void (*wakeup)(struct ao *ao);
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
audio: add device selection & listing with --audio-device 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.
2014-10-09 19:21:31 +00:00
// Return the list of devices currently available in the system. Use
// ao_device_list_add() to add entries. The selected device will be set as
// ao->device (using ao_device_desc.name).
audio: add device change notification for hotplugging Not very important for the command line player; but GUI applications will want to know about this. This only adds the internal API; support for specific audio outputs comes later. This reuses the ao struct as context for the hotplug event listener, similar to how the "old" device listing API did. This is probably a bit unclean and confusing. One argument got reusing it is that otherwise rewriting parts of ao_pulse would be required (because the PulseAudio API requires so damn much boilerplate). Another is that --ao-defaults is applied to the hotplug dummy ao struct, which automatically applies such defaults even to the hotplug context. Notification works through the property observation mechanism in the client API. The notification chain is a bit complicated: the AO notifies the player, which in turn notifies the clients, which in turn will actually retrieve the device list. (It still has the advantage that it's slightly cleaner, since the AO stuff doesn't need to know about client API issues.) The weird handling of atomic flags in ao.c is because we still don't require real atomics from the compiler. Otherwise we'd just use atomic bitwise operations.
2015-02-12 15:53:56 +00:00
// Warning: the ao struct passed is not initialized with ao_driver->init().
// Instead, hotplug_init/hotplug_uninit is called. If these
// callbacks are not set, no driver initialization call is done
// on the ao struct.
audio: change internal device listing API 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.
2014-10-10 16:27:21 +00:00
void (*list_devs)(struct ao *ao, struct ao_device_list *list);
audio: add device selection & listing with --audio-device 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.
2014-10-09 19:21:31 +00:00
audio: add device change notification for hotplugging Not very important for the command line player; but GUI applications will want to know about this. This only adds the internal API; support for specific audio outputs comes later. This reuses the ao struct as context for the hotplug event listener, similar to how the "old" device listing API did. This is probably a bit unclean and confusing. One argument got reusing it is that otherwise rewriting parts of ao_pulse would be required (because the PulseAudio API requires so damn much boilerplate). Another is that --ao-defaults is applied to the hotplug dummy ao struct, which automatically applies such defaults even to the hotplug context. Notification works through the property observation mechanism in the client API. The notification chain is a bit complicated: the AO notifies the player, which in turn notifies the clients, which in turn will actually retrieve the device list. (It still has the advantage that it's slightly cleaner, since the AO stuff doesn't need to know about client API issues.) The weird handling of atomic flags in ao.c is because we still don't require real atomics from the compiler. Otherwise we'd just use atomic bitwise operations.
2015-02-12 15:53:56 +00:00
// If set, these are called before/after ao_driver->list_devs is called.
// It is also assumed that the driver can do hotplugging - which means
// it is expected to call ao_hotplug_event(ao) whenever the system's
// audio device list changes. The player will then call list_devs() again.
int (*hotplug_init)(struct ao *ao);
void (*hotplug_uninit)(struct ao *ao);
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
// For option parsing (see vo.h)
int priv_size;
const void *priv_defaults;
const struct m_option *options;
options: add a mechanism to make sub-option replacement slightly easier Instead of requiring each VO or AO to manually add members to MPOpts and the global option table, make it possible to register them automatically via vo_driver/ao_driver.global_opts members. This avoids modifying options.c/options.h every time, including having to duplicate the exact ifdeffery used to enable a driver.
2016-09-05 19:04:17 +00:00
const struct m_sub_options *global_opts;
options: add automagic hack for handling sub-option deprecations I decided that it's too much work to convert all the VO/AOs to the new option system manually at once. So here's a shitty hack instead, which achieves almost the same thing. (The only user-visible difference is that e.g. --vo=name:help will list the sub-options normally, instead of showing them as deprecation placeholders. Also, the sub-option parser will verify each option normally, instead of deferring to the global option parser.) Another advantage is that once we drop the deprecated options, converting the remaining things will be easier, because we obviously don't need to add the compatibility hacks. Using this mechanism is separate in the next commit to keep the diff noise down.
2016-09-05 19:05:47 +00:00
const char *legacy_prefix;
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
};
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
// These functions can be called by AOs.
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
int ao_play_silence(struct ao *ao, int samples);
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
int ao_read_data(struct ao *ao, void **data, int samples, int64_t out_time_us);
audio/out/push: add a way to wait for the audio device with poll() Will be used for ALSA.
2014-05-29 21:57:11 +00:00
struct pollfd;
int ao_wait_poll(struct ao *ao, struct pollfd *fds, int num_fds,
pthread_mutex_t *lock);
void ao_wakeup_poll(struct ao *ao);
audio/out: feed AOs from a separate thread This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-08 23:04:37 +00:00
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
bool ao_chmap_sel_adjust(struct ao *ao, const struct mp_chmap_sel *s,
struct mp_chmap *map);
audio: use --audio-channels=auto behavior, except on ALSA This commit adds an --audio-channel=auto-safe mode, and makes it the default. This mode behaves like "auto" with most AOs, except with ao_alsa. The intention is to allow multichannel output by default on sane APIs. ALSA is not sane as in it's so low level that it will e.g. configure any layout over HDMI, even if the connected A/V receiver does not support it. The HDMI fuckup is of course not ALSA's fault, but other audio APIs normally isolate applications from dealing with this and require the user to globally configure the correct output layout. This will help with other AOs too. ao_lavc (encoding) is changed to the new semantics as well, because it used to force stereo (perhaps because encoding mode is supposed to produce safe files for crap devices?). Exclusive mode output on Windows might need to be adjusted accordingly, as it grants the same kind of low level access as ALSA (requires more research). In addition to the things mentioned above, the --audio-channels option is extended to accept a set of channel layouts. This is supposed to be the correct way to configure mpv ALSA multichannel output. You need to put a list of channel layouts that your A/V receiver supports.
2016-08-04 18:49:20 +00:00
bool ao_chmap_sel_adjust2(struct ao *ao, const struct mp_chmap_sel *s,
struct mp_chmap *map, bool safe_multichannel);
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
bool ao_chmap_sel_get_def(struct ao *ao, const struct mp_chmap_sel *s,
struct mp_chmap *map, int num);
audio: add device selection & listing with --audio-device 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.
2014-10-09 19:21:31 +00:00
// Add a deep copy of e to the list.
audio: change internal device listing API 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.
2014-10-10 16:27:21 +00:00
// Call from ao_driver->list_devs callback only.
void ao_device_list_add(struct ao_device_list *list, struct ao *ao,
audio: add device selection & listing with --audio-device 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.
2014-10-09 19:21:31 +00:00
struct ao_device_desc *e);
audio/out: deprecate device sub-options We have --audio-device, which can force the device. Also add something describing to this extent to the manpage.
2016-09-05 19:07:30 +00:00
#define DEVICE_OPT_DEPRECATION \
.deprecation_message = "use --audio-device instead"
audio/out: make ao struct opaque We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
2014-03-07 14:24:32 +00:00
#endif
Reference in New Issue Copy Permalink