2007-10-18 13:36:59 +00:00
|
|
|
/*
|
|
|
|
* PulseAudio audio output driver.
|
|
|
|
* Copyright (C) 2006 Lennart Poettering
|
|
|
|
* Copyright (C) 2007 Reimar Doeffinger
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
2008-05-14 18:02:27 +00:00
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with MPlayer; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
2007-10-18 13:36:59 +00:00
|
|
|
*/
|
2008-05-14 18:02:27 +00:00
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
#include <stdlib.h>
|
|
|
|
#include <stdbool.h>
|
2007-10-18 13:36:59 +00:00
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
#include <pulse/pulseaudio.h>
|
|
|
|
|
|
|
|
#include "config.h"
|
2012-11-09 00:06:43 +00:00
|
|
|
#include "audio/format.h"
|
2013-08-06 20:41:30 +00:00
|
|
|
#include "mpvcore/mp_msg.h"
|
2012-11-09 00:06:43 +00:00
|
|
|
#include "ao.h"
|
2013-08-06 20:41:30 +00:00
|
|
|
#include "mpvcore/input/input.h"
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2012-10-11 00:04:08 +00:00
|
|
|
#define PULSE_CLIENT_NAME "mpv"
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2012-11-24 20:40:48 +00:00
|
|
|
#define VOL_PA2MP(v) ((v) * 100 / PA_VOLUME_NORM)
|
|
|
|
#define VOL_MP2PA(v) ((v) * PA_VOLUME_NORM / 100)
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
struct priv {
|
|
|
|
// PulseAudio playback stream object
|
|
|
|
struct pa_stream *stream;
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
// PulseAudio connection context
|
|
|
|
struct pa_context *context;
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
// Main event loop object
|
|
|
|
struct pa_threaded_mainloop *mainloop;
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2012-01-17 06:55:04 +00:00
|
|
|
// temporary during control()
|
|
|
|
struct pa_sink_input_info pi;
|
2009-02-19 14:00:33 +00:00
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
bool broken_pause;
|
|
|
|
int retval;
|
2013-07-21 20:13:11 +00:00
|
|
|
|
|
|
|
char *cfg_host;
|
|
|
|
char *cfg_sink;
|
2012-03-24 15:28:38 +00:00
|
|
|
};
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2013-08-22 21:12:35 +00:00
|
|
|
#define GENERIC_ERR_MSG(str) \
|
|
|
|
MP_ERR(ao, str": %s\n", \
|
|
|
|
pa_strerror(pa_context_errno(((struct priv *)ao->priv)->context)))
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
static void context_state_cb(pa_context *c, void *userdata)
|
|
|
|
{
|
|
|
|
struct ao *ao = userdata;
|
|
|
|
struct priv *priv = ao->priv;
|
2007-10-18 13:36:59 +00:00
|
|
|
switch (pa_context_get_state(c)) {
|
2012-03-24 15:28:38 +00:00
|
|
|
case PA_CONTEXT_READY:
|
|
|
|
case PA_CONTEXT_TERMINATED:
|
|
|
|
case PA_CONTEXT_FAILED:
|
|
|
|
pa_threaded_mainloop_signal(priv->mainloop, 0);
|
|
|
|
break;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
static void stream_state_cb(pa_stream *s, void *userdata)
|
|
|
|
{
|
|
|
|
struct ao *ao = userdata;
|
|
|
|
struct priv *priv = ao->priv;
|
2007-10-18 13:36:59 +00:00
|
|
|
switch (pa_stream_get_state(s)) {
|
2012-03-24 15:28:38 +00:00
|
|
|
case PA_STREAM_READY:
|
|
|
|
case PA_STREAM_FAILED:
|
|
|
|
case PA_STREAM_TERMINATED:
|
|
|
|
pa_threaded_mainloop_signal(priv->mainloop, 0);
|
|
|
|
break;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
static void stream_request_cb(pa_stream *s, size_t length, void *userdata)
|
|
|
|
{
|
|
|
|
struct ao *ao = userdata;
|
|
|
|
struct priv *priv = ao->priv;
|
2012-03-25 19:58:48 +00:00
|
|
|
mp_input_wakeup(ao->input_ctx);
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_threaded_mainloop_signal(priv->mainloop, 0);
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
static void stream_latency_update_cb(pa_stream *s, void *userdata)
|
|
|
|
{
|
|
|
|
struct ao *ao = userdata;
|
|
|
|
struct priv *priv = ao->priv;
|
|
|
|
pa_threaded_mainloop_signal(priv->mainloop, 0);
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
static void success_cb(pa_stream *s, int success, void *userdata)
|
|
|
|
{
|
|
|
|
struct ao *ao = userdata;
|
|
|
|
struct priv *priv = ao->priv;
|
|
|
|
priv->retval = success;
|
|
|
|
pa_threaded_mainloop_signal(priv->mainloop, 0);
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2007-12-15 16:58:25 +00:00
|
|
|
/**
|
|
|
|
* \brief waits for a pulseaudio operation to finish, frees it and
|
|
|
|
* unlocks the mainloop
|
|
|
|
* \param op operation to wait for
|
|
|
|
* \return 1 if operation has finished normally (DONE state), 0 otherwise
|
|
|
|
*/
|
2012-03-24 15:28:38 +00:00
|
|
|
static int waitop(struct priv *priv, pa_operation *op)
|
|
|
|
{
|
2009-04-09 20:04:24 +00:00
|
|
|
if (!op) {
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
2009-04-09 20:04:24 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_operation_state_t state = pa_operation_get_state(op);
|
2007-10-18 13:36:59 +00:00
|
|
|
while (state == PA_OPERATION_RUNNING) {
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_threaded_mainloop_wait(priv->mainloop);
|
2007-10-18 13:36:59 +00:00
|
|
|
state = pa_operation_get_state(op);
|
|
|
|
}
|
|
|
|
pa_operation_unref(op);
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
2007-10-18 13:36:59 +00:00
|
|
|
return state == PA_OPERATION_DONE;
|
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
static const struct format_map {
|
2007-10-18 13:36:59 +00:00
|
|
|
int mp_format;
|
|
|
|
pa_sample_format_t pa_format;
|
|
|
|
} format_maps[] = {
|
|
|
|
{AF_FORMAT_S16_LE, PA_SAMPLE_S16LE},
|
|
|
|
{AF_FORMAT_S16_BE, PA_SAMPLE_S16BE},
|
2008-05-01 16:51:25 +00:00
|
|
|
{AF_FORMAT_S32_LE, PA_SAMPLE_S32LE},
|
|
|
|
{AF_FORMAT_S32_BE, PA_SAMPLE_S32BE},
|
2007-10-18 13:36:59 +00:00
|
|
|
{AF_FORMAT_FLOAT_LE, PA_SAMPLE_FLOAT32LE},
|
|
|
|
{AF_FORMAT_FLOAT_BE, PA_SAMPLE_FLOAT32BE},
|
2008-05-01 16:47:54 +00:00
|
|
|
{AF_FORMAT_U8, PA_SAMPLE_U8},
|
2007-10-18 13:36:59 +00:00
|
|
|
{AF_FORMAT_UNKNOWN, 0}
|
|
|
|
};
|
|
|
|
|
2013-04-06 21:36:00 +00:00
|
|
|
static const int speaker_map[][2] = {
|
|
|
|
{PA_CHANNEL_POSITION_MONO, MP_SPEAKER_ID_FC},
|
|
|
|
{PA_CHANNEL_POSITION_FRONT_LEFT, MP_SPEAKER_ID_FL},
|
|
|
|
{PA_CHANNEL_POSITION_FRONT_RIGHT, MP_SPEAKER_ID_FR},
|
|
|
|
{PA_CHANNEL_POSITION_FRONT_CENTER, MP_SPEAKER_ID_FC},
|
|
|
|
{PA_CHANNEL_POSITION_REAR_CENTER, MP_SPEAKER_ID_BC},
|
|
|
|
{PA_CHANNEL_POSITION_REAR_LEFT, MP_SPEAKER_ID_BL},
|
|
|
|
{PA_CHANNEL_POSITION_REAR_RIGHT, MP_SPEAKER_ID_BR},
|
|
|
|
{PA_CHANNEL_POSITION_LFE, MP_SPEAKER_ID_LFE},
|
|
|
|
{PA_CHANNEL_POSITION_FRONT_LEFT_OF_CENTER, MP_SPEAKER_ID_FLC},
|
|
|
|
{PA_CHANNEL_POSITION_FRONT_RIGHT_OF_CENTER, MP_SPEAKER_ID_FRC},
|
|
|
|
{PA_CHANNEL_POSITION_SIDE_LEFT, MP_SPEAKER_ID_SL},
|
|
|
|
{PA_CHANNEL_POSITION_SIDE_RIGHT, MP_SPEAKER_ID_SR},
|
|
|
|
{PA_CHANNEL_POSITION_TOP_CENTER, MP_SPEAKER_ID_TC},
|
|
|
|
{PA_CHANNEL_POSITION_TOP_FRONT_LEFT, MP_SPEAKER_ID_TFL},
|
|
|
|
{PA_CHANNEL_POSITION_TOP_FRONT_RIGHT, MP_SPEAKER_ID_TFR},
|
|
|
|
{PA_CHANNEL_POSITION_TOP_FRONT_CENTER, MP_SPEAKER_ID_TFC},
|
|
|
|
{PA_CHANNEL_POSITION_TOP_REAR_LEFT, MP_SPEAKER_ID_TBL},
|
|
|
|
{PA_CHANNEL_POSITION_TOP_REAR_RIGHT, MP_SPEAKER_ID_TBR},
|
|
|
|
{PA_CHANNEL_POSITION_TOP_REAR_CENTER, MP_SPEAKER_ID_TBC},
|
|
|
|
{PA_CHANNEL_POSITION_INVALID, -1}
|
|
|
|
};
|
|
|
|
|
|
|
|
static bool chmap_pa_from_mp(pa_channel_map *dst, struct mp_chmap *src)
|
|
|
|
{
|
|
|
|
if (src->num > PA_CHANNELS_MAX)
|
|
|
|
return false;
|
|
|
|
dst->channels = src->num;
|
|
|
|
for (int n = 0; n < src->num; n++) {
|
|
|
|
int mp_speaker = src->speaker[n];
|
|
|
|
int pa_speaker = PA_CHANNEL_POSITION_INVALID;
|
|
|
|
for (int i = 0; speaker_map[i][1] != -1; i++) {
|
|
|
|
if (speaker_map[i][1] == mp_speaker) {
|
|
|
|
pa_speaker = speaker_map[i][0];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (pa_speaker == PA_CHANNEL_POSITION_INVALID)
|
|
|
|
return false;
|
|
|
|
dst->map[n] = pa_speaker;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-05-09 16:06:26 +00:00
|
|
|
static bool select_chmap(struct ao *ao, pa_channel_map *dst)
|
|
|
|
{
|
|
|
|
struct mp_chmap_sel sel = {0};
|
|
|
|
for (int n = 0; speaker_map[n][1] != -1; n++)
|
|
|
|
mp_chmap_sel_add_speaker(&sel, speaker_map[n][1]);
|
|
|
|
return ao_chmap_sel_adjust(ao, &sel, &ao->channels) &&
|
|
|
|
chmap_pa_from_mp(dst, &ao->channels);
|
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
static void uninit(struct ao *ao, bool cut_audio)
|
|
|
|
{
|
|
|
|
struct priv *priv = ao->priv;
|
|
|
|
if (priv->stream && !cut_audio) {
|
|
|
|
pa_threaded_mainloop_lock(priv->mainloop);
|
|
|
|
waitop(priv, pa_stream_drain(priv->stream, success_cb, ao));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (priv->mainloop)
|
|
|
|
pa_threaded_mainloop_stop(priv->mainloop);
|
|
|
|
|
|
|
|
if (priv->stream) {
|
|
|
|
pa_stream_disconnect(priv->stream);
|
|
|
|
pa_stream_unref(priv->stream);
|
|
|
|
priv->stream = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (priv->context) {
|
|
|
|
pa_context_disconnect(priv->context);
|
|
|
|
pa_context_unref(priv->context);
|
|
|
|
priv->context = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (priv->mainloop) {
|
|
|
|
pa_threaded_mainloop_free(priv->mainloop);
|
|
|
|
priv->mainloop = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-22 20:57:51 +00:00
|
|
|
static int init(struct ao *ao)
|
2012-03-24 15:28:38 +00:00
|
|
|
{
|
2007-10-18 13:36:59 +00:00
|
|
|
struct pa_sample_spec ss;
|
|
|
|
struct pa_channel_map map;
|
2013-09-20 03:58:08 +00:00
|
|
|
pa_proplist *proplist = NULL;
|
2013-07-21 20:13:11 +00:00
|
|
|
struct priv *priv = ao->priv;
|
|
|
|
char *host = priv->cfg_host && priv->cfg_host[0] ? priv->cfg_host : NULL;
|
|
|
|
char *sink = priv->cfg_sink && priv->cfg_sink[0] ? priv->cfg_sink : NULL;
|
2009-12-18 20:27:35 +00:00
|
|
|
const char *version = pa_get_library_version();
|
2007-10-18 13:36:59 +00:00
|
|
|
|
softvol, ao_pulse: prefer ao_pulse volume control by default
--softvol is enabled by default. For most audio outputs, this is a good
thing, as they have either their own (bad) soft volume implementation,
or control the system mixer. With ao_pulse, the situation is a bit
different: it supports per-application volume (i.e. volume control is
not really global). More importantly, ao_pulse uses a rather large audio
buffer, and changing the volume with mplayer's volume filter has a large
delay. With the native ao_pulse volume control, it's instant, because
PulseAudio's audio filtering happens at a later stage in its processing
pipeline (inaccessible for mplayer).
This means native volume control should really be allowed for ao_pulse,
while it's the reverse for other audio outputs. Make --softvol a choice
option, and add a new "auto" choice. This is default and will use PA's
volume control with ao_pulse, and mplayer's volume filter otherwise
(i.e. the old softvol behavior).
2012-09-18 19:41:22 +00:00
|
|
|
ao->per_application_mixer = true;
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
priv->broken_pause = false;
|
|
|
|
/* not sure which versions are affected, assume 0.9.11* to 0.9.14*
|
|
|
|
* known bad: 0.9.14, 0.9.13
|
|
|
|
* known good: 0.9.9, 0.9.10, 0.9.15
|
|
|
|
* To test: pause, wait ca. 5 seconds, framestep and see if MPlayer
|
|
|
|
* hangs somewhen. */
|
|
|
|
if (strncmp(version, "0.9.1", 5) == 0 && version[5] >= '1'
|
|
|
|
&& version[5] <= '4') {
|
2013-08-22 21:12:35 +00:00
|
|
|
MP_WARN(ao, "working around probably broken pause functionality,\n"
|
|
|
|
" see http://www.pulseaudio.org/ticket/440\n");
|
2012-03-24 15:28:38 +00:00
|
|
|
priv->broken_pause = true;
|
2009-02-19 14:00:33 +00:00
|
|
|
}
|
|
|
|
|
2013-05-09 15:34:17 +00:00
|
|
|
if (!(priv->mainloop = pa_threaded_mainloop_new())) {
|
2013-08-22 21:12:35 +00:00
|
|
|
MP_ERR(ao, "Failed to allocate main loop\n");
|
2013-05-09 15:34:17 +00:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(priv->context = pa_context_new(pa_threaded_mainloop_get_api(
|
|
|
|
priv->mainloop), PULSE_CLIENT_NAME))) {
|
2013-08-22 21:12:35 +00:00
|
|
|
MP_ERR(ao, "Failed to allocate context\n");
|
2013-05-09 15:34:17 +00:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
pa_context_set_state_callback(priv->context, context_state_cb, ao);
|
|
|
|
|
|
|
|
if (pa_context_connect(priv->context, host, 0, NULL) < 0)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
pa_threaded_mainloop_lock(priv->mainloop);
|
|
|
|
|
|
|
|
if (pa_threaded_mainloop_start(priv->mainloop) < 0)
|
|
|
|
goto unlock_and_fail;
|
|
|
|
|
|
|
|
/* Wait until the context is ready */
|
|
|
|
pa_threaded_mainloop_wait(priv->mainloop);
|
|
|
|
|
|
|
|
if (pa_context_get_state(priv->context) != PA_CONTEXT_READY)
|
|
|
|
goto unlock_and_fail;
|
|
|
|
|
2013-04-05 21:06:22 +00:00
|
|
|
ss.channels = ao->channels.num;
|
2012-03-24 15:28:38 +00:00
|
|
|
ss.rate = ao->samplerate;
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
const struct format_map *fmt_map = format_maps;
|
|
|
|
while (fmt_map->mp_format != ao->format) {
|
2007-10-18 13:36:59 +00:00
|
|
|
if (fmt_map->mp_format == AF_FORMAT_UNKNOWN) {
|
2013-08-22 21:12:35 +00:00
|
|
|
MP_VERBOSE(ao, "Unsupported format, using default\n");
|
2008-05-01 16:47:54 +00:00
|
|
|
fmt_map = format_maps;
|
|
|
|
break;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
fmt_map++;
|
|
|
|
}
|
2012-03-24 15:28:38 +00:00
|
|
|
ao->format = fmt_map->mp_format;
|
2007-10-18 13:36:59 +00:00
|
|
|
ss.format = fmt_map->pa_format;
|
|
|
|
|
|
|
|
if (!pa_sample_spec_valid(&ss)) {
|
2013-08-22 21:12:35 +00:00
|
|
|
MP_ERR(ao, "Invalid sample spec\n");
|
2013-09-20 03:58:18 +00:00
|
|
|
goto unlock_and_fail;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2013-05-09 16:06:26 +00:00
|
|
|
if (!select_chmap(ao, &map))
|
2013-09-20 03:58:18 +00:00
|
|
|
goto unlock_and_fail;
|
2013-04-05 21:06:22 +00:00
|
|
|
|
2013-09-20 03:58:08 +00:00
|
|
|
if (!(proplist = pa_proplist_new())) {
|
|
|
|
MP_ERR(ao, "Failed to allocate proplist\n");
|
|
|
|
goto unlock_and_fail;
|
|
|
|
}
|
|
|
|
(void)pa_proplist_sets(proplist, PA_PROP_MEDIA_ROLE, "video");
|
|
|
|
|
|
|
|
if (!(priv->stream = pa_stream_new_with_proplist(priv->context,
|
|
|
|
"audio stream", &ss,
|
|
|
|
&map, proplist)))
|
2007-10-18 13:36:59 +00:00
|
|
|
goto unlock_and_fail;
|
|
|
|
|
2013-09-20 03:58:08 +00:00
|
|
|
pa_proplist_free(proplist);
|
|
|
|
proplist = NULL;
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_stream_set_state_callback(priv->stream, stream_state_cb, ao);
|
|
|
|
pa_stream_set_write_callback(priv->stream, stream_request_cb, ao);
|
|
|
|
pa_stream_set_latency_update_callback(priv->stream,
|
|
|
|
stream_latency_update_cb, ao);
|
2012-03-25 19:58:48 +00:00
|
|
|
pa_buffer_attr bufattr = {
|
|
|
|
.maxlength = -1,
|
|
|
|
.tlength = pa_usec_to_bytes(1000000, &ss),
|
|
|
|
.prebuf = -1,
|
|
|
|
.minreq = -1,
|
|
|
|
.fragsize = -1,
|
|
|
|
};
|
|
|
|
if (pa_stream_connect_playback(priv->stream, sink, &bufattr,
|
ao_pulse: work around PulseAudio timing bugs
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
2012-07-29 17:56:31 +00:00
|
|
|
PA_STREAM_NOT_MONOTONIC, NULL, NULL) < 0)
|
2007-10-18 13:36:59 +00:00
|
|
|
goto unlock_and_fail;
|
|
|
|
|
|
|
|
/* Wait until the stream is ready */
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_threaded_mainloop_wait(priv->mainloop);
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
if (pa_stream_get_state(priv->stream) != PA_STREAM_READY)
|
2007-10-18 13:36:59 +00:00
|
|
|
goto unlock_and_fail;
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
2007-10-18 13:36:59 +00:00
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
return 0;
|
2007-10-18 13:36:59 +00:00
|
|
|
|
|
|
|
unlock_and_fail:
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
if (priv->mainloop)
|
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
2007-10-18 13:36:59 +00:00
|
|
|
|
|
|
|
fail:
|
2012-07-29 20:46:10 +00:00
|
|
|
if (priv->context) {
|
|
|
|
if (!(pa_context_errno(priv->context) == PA_ERR_CONNECTIONREFUSED
|
|
|
|
&& ao->probing))
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("Init failed");
|
2012-07-29 20:46:10 +00:00
|
|
|
}
|
2013-09-20 03:58:08 +00:00
|
|
|
|
|
|
|
if (proplist)
|
|
|
|
pa_proplist_free(proplist);
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
uninit(ao, true);
|
|
|
|
return -1;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
static void cork(struct ao *ao, bool pause)
|
|
|
|
{
|
|
|
|
struct priv *priv = ao->priv;
|
|
|
|
pa_threaded_mainloop_lock(priv->mainloop);
|
|
|
|
priv->retval = 0;
|
|
|
|
if (!waitop(priv, pa_stream_cork(priv->stream, pause, success_cb, ao)) ||
|
|
|
|
!priv->retval)
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("pa_stream_cork() failed");
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
// Play the specified data to the pulseaudio server
|
|
|
|
static int play(struct ao *ao, void *data, int len, int flags)
|
|
|
|
{
|
|
|
|
struct priv *priv = ao->priv;
|
|
|
|
pa_threaded_mainloop_lock(priv->mainloop);
|
|
|
|
if (pa_stream_write(priv->stream, data, len, NULL, 0,
|
|
|
|
PA_SEEK_RELATIVE) < 0) {
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("pa_stream_write() failed");
|
2007-12-15 17:10:06 +00:00
|
|
|
len = -1;
|
2007-12-15 17:07:40 +00:00
|
|
|
}
|
ao_pulse: work around PulseAudio timing bugs
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
2012-07-29 17:56:31 +00:00
|
|
|
if (flags & AOPLAY_FINAL_CHUNK) {
|
|
|
|
// Force start in case the stream was too short for prebuf
|
|
|
|
pa_operation *op = pa_stream_trigger(priv->stream, NULL, NULL);
|
|
|
|
pa_operation_unref(op);
|
|
|
|
}
|
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
2007-10-18 13:36:59 +00:00
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
// Reset the audio stream, i.e. flush the playback buffer on the server side
|
|
|
|
static void reset(struct ao *ao)
|
|
|
|
{
|
2012-03-26 00:47:44 +00:00
|
|
|
// pa_stream_flush() works badly if not corked
|
|
|
|
cork(ao, true);
|
2012-03-24 15:28:38 +00:00
|
|
|
struct priv *priv = ao->priv;
|
|
|
|
pa_threaded_mainloop_lock(priv->mainloop);
|
|
|
|
priv->retval = 0;
|
|
|
|
if (!waitop(priv, pa_stream_flush(priv->stream, success_cb, ao)) ||
|
|
|
|
!priv->retval)
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("pa_stream_flush() failed");
|
ao_pulse: work around PulseAudio timing bugs
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
2012-07-29 17:56:31 +00:00
|
|
|
cork(ao, false);
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
// Pause the audio stream by corking it on the server
|
|
|
|
static void pause(struct ao *ao)
|
|
|
|
{
|
|
|
|
cork(ao, true);
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
// Resume the audio stream by uncorking it on the server
|
|
|
|
static void resume(struct ao *ao)
|
|
|
|
{
|
|
|
|
struct priv *priv = ao->priv;
|
|
|
|
/* Without this, certain versions will cause an infinite hang because
|
|
|
|
* pa_stream_writable_size returns 0 always.
|
|
|
|
* Note that this workaround causes A-V desync after pause. */
|
|
|
|
if (priv->broken_pause)
|
|
|
|
reset(ao);
|
|
|
|
cork(ao, false);
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
// Return number of bytes that may be written to the server without blocking
|
|
|
|
static int get_space(struct ao *ao)
|
|
|
|
{
|
|
|
|
struct priv *priv = ao->priv;
|
|
|
|
pa_threaded_mainloop_lock(priv->mainloop);
|
|
|
|
size_t space = pa_stream_writable_size(priv->stream);
|
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
|
|
|
return space;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
// Return the current latency in seconds
|
|
|
|
static float get_delay(struct ao *ao)
|
|
|
|
{
|
ao_pulse: work around PulseAudio timing bugs
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
2012-07-29 17:56:31 +00:00
|
|
|
/* This code basically does what pa_stream_get_latency() _should_
|
|
|
|
* do, but doesn't due to multiple known bugs in PulseAudio (at
|
|
|
|
* PulseAudio version 2.1). In particular, the timing interpolation
|
|
|
|
* mode (PA_STREAM_INTERPOLATE_TIMING) can return completely bogus
|
|
|
|
* values, and the non-interpolating code has a bug causing too
|
|
|
|
* large results at end of stream (so a stream never seems to finish).
|
|
|
|
* This code can still return wrong values in some cases due to known
|
|
|
|
* PulseAudio bugs that can not be worked around on the client side.
|
|
|
|
*
|
|
|
|
* We always query the server for latest timing info. This may take
|
|
|
|
* too long to work well with remote audio servers, but at least
|
|
|
|
* this should be enough to fix the normal local playback case.
|
|
|
|
*/
|
2012-03-24 15:28:38 +00:00
|
|
|
struct priv *priv = ao->priv;
|
|
|
|
pa_threaded_mainloop_lock(priv->mainloop);
|
ao_pulse: work around PulseAudio timing bugs
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
2012-07-29 17:56:31 +00:00
|
|
|
if (!waitop(priv, pa_stream_update_timing_info(priv->stream, NULL, NULL))) {
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("pa_stream_update_timing_info() failed");
|
ao_pulse: work around PulseAudio timing bugs
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
2012-07-29 17:56:31 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
pa_threaded_mainloop_lock(priv->mainloop);
|
|
|
|
const pa_timing_info *ti = pa_stream_get_timing_info(priv->stream);
|
|
|
|
if (!ti) {
|
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("pa_stream_get_timing_info() failed");
|
ao_pulse: work around PulseAudio timing bugs
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
2012-07-29 17:56:31 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
const struct pa_sample_spec *ss = pa_stream_get_sample_spec(priv->stream);
|
|
|
|
if (!ss) {
|
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("pa_stream_get_sample_spec() failed");
|
ao_pulse: work around PulseAudio timing bugs
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
2012-07-29 17:56:31 +00:00
|
|
|
return 0;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
ao_pulse: work around PulseAudio timing bugs
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
2012-07-29 17:56:31 +00:00
|
|
|
// data left in PulseAudio's main buffers (not written to sink yet)
|
|
|
|
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
|
|
|
|
// since this info may be from a while ago, playback has progressed since
|
|
|
|
latency -= ti->transport_usec;
|
|
|
|
// data already moved from buffers to sink, but not played yet
|
|
|
|
int64_t sink_latency = ti->sink_usec;
|
|
|
|
if (!ti->playing)
|
|
|
|
/* At the end of a stream, part of the data "left" in the sink may
|
|
|
|
* be padding silence after the end; that should be subtracted to
|
|
|
|
* get the amount of real audio from our stream. This adjustment
|
|
|
|
* is missing from Pulseaudio's own get_latency calculations
|
|
|
|
* (as of PulseAudio 2.1). */
|
|
|
|
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
|
|
|
|
if (sink_latency > 0)
|
|
|
|
latency += sink_latency;
|
|
|
|
if (latency < 0)
|
|
|
|
latency = 0;
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
ao_pulse: work around PulseAudio timing bugs
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
2012-07-29 17:56:31 +00:00
|
|
|
return latency / 1e6;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
/* A callback function that is called when the
|
2007-10-18 13:36:59 +00:00
|
|
|
* pa_context_get_sink_input_info() operation completes. Saves the
|
2012-03-24 15:28:38 +00:00
|
|
|
* volume field of the specified structure to the global variable volume.
|
|
|
|
*/
|
|
|
|
static void info_func(struct pa_context *c, const struct pa_sink_input_info *i,
|
|
|
|
int is_last, void *userdata)
|
|
|
|
{
|
|
|
|
struct ao *ao = userdata;
|
|
|
|
struct priv *priv = ao->priv;
|
2007-10-18 13:36:59 +00:00
|
|
|
if (is_last < 0) {
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("Failed to get sink input info");
|
2007-10-18 13:36:59 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (!i)
|
|
|
|
return;
|
2012-01-17 06:55:04 +00:00
|
|
|
priv->pi = *i;
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_threaded_mainloop_signal(priv->mainloop, 0);
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
|
2012-04-07 13:26:56 +00:00
|
|
|
static int control(struct ao *ao, enum aocontrol cmd, void *arg)
|
2012-03-24 15:28:38 +00:00
|
|
|
{
|
|
|
|
struct priv *priv = ao->priv;
|
2007-10-18 13:36:59 +00:00
|
|
|
switch (cmd) {
|
2012-01-17 06:55:04 +00:00
|
|
|
case AOCONTROL_GET_MUTE:
|
2012-03-24 15:28:38 +00:00
|
|
|
case AOCONTROL_GET_VOLUME: {
|
|
|
|
uint32_t devidx = pa_stream_get_index(priv->stream);
|
|
|
|
pa_threaded_mainloop_lock(priv->mainloop);
|
|
|
|
if (!waitop(priv, pa_context_get_sink_input_info(priv->context, devidx,
|
|
|
|
info_func, ao))) {
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("pa_stream_get_sink_input_info() failed");
|
2012-03-24 15:28:38 +00:00
|
|
|
return CONTROL_ERROR;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
2012-01-17 06:55:04 +00:00
|
|
|
// Warning: some information in pi might be unaccessible, because
|
|
|
|
// we naively copied the struct, without updating pointers etc.
|
|
|
|
// Pointers might point to invalid data, accessors might fail.
|
|
|
|
if (cmd == AOCONTROL_GET_VOLUME) {
|
|
|
|
ao_control_vol_t *vol = arg;
|
|
|
|
if (priv->pi.volume.channels != 2)
|
|
|
|
vol->left = vol->right =
|
2012-09-18 19:42:09 +00:00
|
|
|
VOL_PA2MP(pa_cvolume_avg(&priv->pi.volume));
|
2012-01-17 06:55:04 +00:00
|
|
|
else {
|
2012-09-18 19:42:09 +00:00
|
|
|
vol->left = VOL_PA2MP(priv->pi.volume.values[0]);
|
|
|
|
vol->right = VOL_PA2MP(priv->pi.volume.values[1]);
|
2012-01-17 06:55:04 +00:00
|
|
|
}
|
|
|
|
} else if (cmd == AOCONTROL_GET_MUTE) {
|
|
|
|
bool *mute = arg;
|
|
|
|
*mute = priv->pi.mute;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
2012-03-24 15:28:38 +00:00
|
|
|
return CONTROL_OK;
|
|
|
|
}
|
2012-01-17 06:55:04 +00:00
|
|
|
|
|
|
|
case AOCONTROL_SET_MUTE:
|
2012-03-24 15:28:38 +00:00
|
|
|
case AOCONTROL_SET_VOLUME: {
|
|
|
|
pa_operation *o;
|
2012-01-17 06:55:04 +00:00
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
pa_threaded_mainloop_lock(priv->mainloop);
|
2012-01-17 06:55:04 +00:00
|
|
|
uint32_t stream_index = pa_stream_get_index(priv->stream);
|
|
|
|
if (cmd == AOCONTROL_SET_VOLUME) {
|
|
|
|
const ao_control_vol_t *vol = arg;
|
|
|
|
struct pa_cvolume volume;
|
|
|
|
|
2013-04-05 21:06:22 +00:00
|
|
|
pa_cvolume_reset(&volume, ao->channels.num);
|
2012-01-17 06:55:04 +00:00
|
|
|
if (volume.channels != 2)
|
2012-09-18 19:42:09 +00:00
|
|
|
pa_cvolume_set(&volume, volume.channels, VOL_MP2PA(vol->left));
|
2012-01-17 06:55:04 +00:00
|
|
|
else {
|
2012-09-18 19:42:09 +00:00
|
|
|
volume.values[0] = VOL_MP2PA(vol->left);
|
|
|
|
volume.values[1] = VOL_MP2PA(vol->right);
|
2012-01-17 06:55:04 +00:00
|
|
|
}
|
|
|
|
o = pa_context_set_sink_input_volume(priv->context, stream_index,
|
|
|
|
&volume, NULL, NULL);
|
|
|
|
if (!o) {
|
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("pa_context_set_sink_input_volume() failed");
|
2012-01-17 06:55:04 +00:00
|
|
|
return CONTROL_ERROR;
|
|
|
|
}
|
|
|
|
} else if (cmd == AOCONTROL_SET_MUTE) {
|
|
|
|
const bool *mute = arg;
|
|
|
|
o = pa_context_set_sink_input_mute(priv->context, stream_index,
|
|
|
|
*mute, NULL, NULL);
|
|
|
|
if (!o) {
|
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
2013-08-22 21:12:35 +00:00
|
|
|
GENERIC_ERR_MSG("pa_context_set_sink_input_mute() failed");
|
2012-01-17 06:55:04 +00:00
|
|
|
return CONTROL_ERROR;
|
|
|
|
}
|
|
|
|
} else
|
|
|
|
abort();
|
2012-03-24 15:28:38 +00:00
|
|
|
/* We don't wait for completion here */
|
|
|
|
pa_operation_unref(o);
|
|
|
|
pa_threaded_mainloop_unlock(priv->mainloop);
|
|
|
|
return CONTROL_OK;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
return CONTROL_UNKNOWN;
|
2007-10-18 13:36:59 +00:00
|
|
|
}
|
|
|
|
}
|
2012-03-24 15:28:38 +00:00
|
|
|
|
2013-07-21 20:13:11 +00:00
|
|
|
#define OPT_BASE_STRUCT struct priv
|
|
|
|
|
2012-03-24 15:28:38 +00:00
|
|
|
const struct ao_driver audio_out_pulse = {
|
|
|
|
.info = &(const struct ao_info) {
|
|
|
|
"PulseAudio audio output",
|
|
|
|
"pulse",
|
|
|
|
"Lennart Poettering",
|
|
|
|
"",
|
|
|
|
},
|
|
|
|
.control = control,
|
|
|
|
.init = init,
|
|
|
|
.uninit = uninit,
|
|
|
|
.reset = reset,
|
|
|
|
.get_space = get_space,
|
|
|
|
.play = play,
|
|
|
|
.get_delay = get_delay,
|
|
|
|
.pause = pause,
|
|
|
|
.resume = resume,
|
2013-07-21 20:13:11 +00:00
|
|
|
.priv_size = sizeof(struct priv),
|
|
|
|
.options = (const struct m_option[]) {
|
|
|
|
OPT_STRING("host", cfg_host, 0),
|
|
|
|
OPT_STRING("sink", cfg_sink, 0),
|
|
|
|
{0}
|
|
|
|
},
|
2012-03-24 15:28:38 +00:00
|
|
|
};
|