mpv/audio/out/ao_jack.c

244 lines
5.9 KiB
C
Raw Normal View History

/*
* JACK audio output driver for MPlayer
*
* Copyleft 2001 by Felix Bünemann (atmosfear@users.sf.net)
* and Reimar Döffinger (Reimar.Doeffinger@stud.uni-karlsruhe.de)
*
* Copyleft 2013 by William Light <wrl@illest.net> for the mpv project
*
* This file is part of MPlayer.
*
* MPlayer is free software; you can redistribute it and/or modify
* 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.
*
* MPlayer 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
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* along with MPlayer; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include "config.h"
#include "common/msg.h"
#include "ao.h"
#include "internal.h"
#include "audio/format.h"
#include "osdep/timer.h"
#include "options/m_option.h"
#include <jack/jack.h>
2013-06-07 14:42:29 +00:00
struct priv {
jack_client_t *client;
float jack_latency;
2013-07-21 22:03:57 +00:00
char *cfg_port;
char *cfg_client_name;
int connect;
int autostart;
int stdlayout;
int last_chunk;
int num_ports;
jack_port_t *ports[MP_NUM_CHANNELS];
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 activated;
};
static int process(jack_nframes_t nframes, void *arg)
2013-06-07 13:38:08 +00:00
{
2013-06-07 13:44:49 +00:00
struct ao *ao = arg;
2013-06-07 14:42:29 +00:00
struct priv *p = ao->priv;
void *buffers[MP_NUM_CHANNELS];
for (int i = 0; i < p->num_ports; i++)
buffers[i] = jack_port_get_buffer(p->ports[i], nframes);
int64_t end_time = mp_time_us();
end_time += (p->jack_latency + nframes / (double)ao->samplerate) * 1000000.0;
ao_read_data(ao, buffers, nframes, end_time);
2013-06-07 13:38:08 +00:00
return 0;
}
static int
connect_to_outports(struct ao *ao)
{
2013-07-21 22:03:57 +00:00
struct priv *p = ao->priv;
char *port_name = (p->cfg_port && p->cfg_port[0]) ? p->cfg_port : NULL;
2013-06-07 13:38:08 +00:00
const char **matching_ports = NULL;
int port_flags = JackPortIsInput;
int i;
if (!port_name)
port_flags |= JackPortIsPhysical;
matching_ports = jack_get_ports(p->client, port_name, NULL, port_flags);
if (!matching_ports || !matching_ports[0]) {
MP_FATAL(ao, "no ports to connect to\n");
goto err_get_ports;
}
for (i = 0; i < p->num_ports && matching_ports[i]; i++) {
if (jack_connect(p->client, jack_port_name(p->ports[i]),
matching_ports[i]))
{
MP_FATAL(ao, "connecting failed\n");
goto err_connect;
}
}
free(matching_ports);
return 0;
err_connect:
free(matching_ports);
err_get_ports:
return -1;
}
static int
create_ports(struct ao *ao, int nports)
{
struct priv *p = ao->priv;
char pname[30];
int i;
for (i = 0; i < nports; i++) {
snprintf(pname, sizeof(pname), "out_%d", i);
p->ports[i] = jack_port_register(p->client, pname, JACK_DEFAULT_AUDIO_TYPE,
JackPortIsOutput, 0);
if (!p->ports[i]) {
MP_FATAL(ao, "not enough ports available\n");
goto err_port_register;
}
}
p->num_ports = nports;
return 0;
err_port_register:
return -1;
}
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
static void resume(struct ao *ao)
{
struct priv *p = ao->priv;
if (!p->activated) {
p->activated = true;
if (jack_activate(p->client))
MP_FATAL(ao, "activate failed\n");
if (p->connect)
connect_to_outports(ao);
}
}
static int init(struct ao *ao)
{
struct priv *p = ao->priv;
2013-06-07 13:38:08 +00:00
struct mp_chmap_sel sel = {0};
jack_options_t open_options;
ao->format = AF_FORMAT_FLOATP;
switch (p->stdlayout) {
case 0:
mp_chmap_sel_add_waveext(&sel);
break;
case 1:
2013-07-21 22:03:57 +00:00
mp_chmap_sel_add_alsa_def(&sel);
break;
default:
2013-07-21 22:03:57 +00:00
mp_chmap_sel_add_any(&sel);
}
2013-06-07 13:44:49 +00:00
if (!ao_chmap_sel_adjust(ao, &sel, &ao->channels))
goto err_chmap;
2013-06-07 13:38:08 +00:00
open_options = JackNullOption;
2013-07-21 22:03:57 +00:00
if (!p->autostart)
2013-06-07 13:38:08 +00:00
open_options |= JackNoStartServer;
2013-07-21 22:03:57 +00:00
p->client = jack_client_open(p->cfg_client_name, open_options, NULL);
2013-06-07 14:42:29 +00:00
if (!p->client) {
MP_FATAL(ao, "cannot open server\n");
goto err_client_open;
}
2013-06-07 13:38:08 +00:00
if (create_ports(ao, ao->channels.num))
goto err_create_ports;
jack_set_process_callback(p->client, process, ao);
2013-06-07 13:38:08 +00:00
2013-06-07 14:42:29 +00:00
ao->samplerate = jack_get_sample_rate(p->client);
2013-06-07 13:38:08 +00:00
jack_latency_range_t jack_latency_range;
jack_port_get_latency_range(p->ports[0], JackPlaybackLatency,
2013-06-07 13:38:08 +00:00
&jack_latency_range);
2013-06-07 14:42:29 +00:00
p->jack_latency = (float)(jack_latency_range.max + jack_get_buffer_size(p->client))
/ (float)ao->samplerate;
2013-06-07 13:38:08 +00:00
2013-06-07 14:42:29 +00:00
if (!ao_chmap_sel_get_def(ao, &sel, &ao->channels, p->num_ports))
goto err_chmap_sel_get_def;
2013-06-07 13:38:08 +00:00
2013-06-07 13:44:49 +00:00
return 0;
err_chmap_sel_get_def:
err_create_ports:
jack_client_close(p->client);
err_client_open:
err_chmap:
2013-06-07 13:44:49 +00:00
return -1;
}
2013-06-07 13:44:49 +00:00
// close audio device
static void uninit(struct ao *ao)
2013-06-07 13:44:49 +00:00
{
2013-06-07 14:42:29 +00:00
struct priv *p = ao->priv;
2013-06-07 14:42:29 +00:00
jack_client_close(p->client);
2013-06-07 13:44:49 +00:00
}
2013-07-21 22:03:57 +00:00
#define OPT_BASE_STRUCT struct priv
2013-06-07 13:44:49 +00:00
const struct ao_driver audio_out_jack = {
.description = "JACK audio output",
.name = "jack",
2013-06-07 13:44:49 +00:00
.init = init,
.uninit = 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 = resume,
2013-07-21 22:03:57 +00:00
.priv_size = sizeof(struct priv),
.priv_defaults = &(const struct priv) {
.cfg_client_name = "mpv",
.connect = 1,
},
.options = (const struct m_option[]) {
OPT_STRING("port", cfg_port, 0),
OPT_STRING("name", cfg_client_name, 0),
OPT_FLAG("autostart", autostart, 0),
OPT_FLAG("connect", connect, 0),
OPT_CHOICE("std-channel-layout", stdlayout, 0,
({"waveext", 0}, {"alsa", 1}, {"any", 2})),
2013-07-21 22:03:57 +00:00
{0}
},
2013-06-07 13:44:49 +00:00
};