mpv/audio/out/ao_pulse.c

612 lines
20 KiB
C
Raw Normal View History

/*
* 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.
*
* 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.
*/
2012-03-24 15:28:38 +00:00
#include <stdlib.h>
#include <stdbool.h>
#include <string.h>
#include <pulse/pulseaudio.h>
#include "config.h"
#include "audio/format.h"
#include "mpvcore/mp_msg.h"
#include "ao.h"
#include "mpvcore/input/input.h"
#define PULSE_CLIENT_NAME "mpv"
#define VOL_PA2MP(v) ((v) * 100 / PA_VOLUME_NORM)
#define VOL_MP2PA(v) ((v) * PA_VOLUME_NORM / 100)
2012-03-24 15:28:38 +00:00
struct priv {
// PulseAudio playback stream object
struct pa_stream *stream;
2012-03-24 15:28:38 +00:00
// PulseAudio connection context
struct pa_context *context;
2012-03-24 15:28:38 +00:00
// Main event loop object
struct pa_threaded_mainloop *mainloop;
2012-01-17 06:55:04 +00:00
// temporary during control()
struct pa_sink_input_info pi;
2012-03-24 15:28:38 +00:00
bool broken_pause;
int retval;
char *cfg_host;
char *cfg_sink;
2012-03-24 15:28:38 +00:00
};
#define GENERIC_ERR_MSG(str) \
MP_ERR(ao, str": %s\n", \
pa_strerror(pa_context_errno(((struct priv *)ao->priv)->context)))
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;
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;
}
}
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;
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;
}
}
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;
mp_input_wakeup(ao->input_ctx);
2012-03-24 15:28:38 +00:00
pa_threaded_mainloop_signal(priv->mainloop, 0);
}
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);
}
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);
}
/**
* \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)
{
if (!op) {
2012-03-24 15:28:38 +00:00
pa_threaded_mainloop_unlock(priv->mainloop);
return 0;
}
2012-03-24 15:28:38 +00:00
pa_operation_state_t state = pa_operation_get_state(op);
while (state == PA_OPERATION_RUNNING) {
2012-03-24 15:28:38 +00:00
pa_threaded_mainloop_wait(priv->mainloop);
state = pa_operation_get_state(op);
}
pa_operation_unref(op);
2012-03-24 15:28:38 +00:00
pa_threaded_mainloop_unlock(priv->mainloop);
return state == PA_OPERATION_DONE;
}
2012-03-24 15:28:38 +00:00
static const struct format_map {
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},
{AF_FORMAT_S32_LE, PA_SAMPLE_S32LE},
{AF_FORMAT_S32_BE, PA_SAMPLE_S32BE},
{AF_FORMAT_FLOAT_LE, PA_SAMPLE_FLOAT32LE},
{AF_FORMAT_FLOAT_BE, PA_SAMPLE_FLOAT32BE},
{AF_FORMAT_U8, PA_SAMPLE_U8},
{AF_FORMAT_UNKNOWN, 0}
};
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;
}
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;
}
}
static int init(struct ao *ao)
2012-03-24 15:28:38 +00:00
{
struct pa_sample_spec ss;
struct pa_channel_map map;
pa_proplist *proplist = NULL;
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;
const char *version = pa_get_library_version();
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') {
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;
}
2013-05-09 15:34:17 +00:00
if (!(priv->mainloop = pa_threaded_mainloop_new())) {
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))) {
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;
ss.channels = ao->channels.num;
2012-03-24 15:28:38 +00:00
ss.rate = ao->samplerate;
2012-03-24 15:28:38 +00:00
const struct format_map *fmt_map = format_maps;
while (fmt_map->mp_format != ao->format) {
if (fmt_map->mp_format == AF_FORMAT_UNKNOWN) {
MP_VERBOSE(ao, "Unsupported format, using default\n");
fmt_map = format_maps;
break;
}
fmt_map++;
}
2012-03-24 15:28:38 +00:00
ao->format = fmt_map->mp_format;
ss.format = fmt_map->pa_format;
if (!pa_sample_spec_valid(&ss)) {
MP_ERR(ao, "Invalid sample spec\n");
goto unlock_and_fail;
}
if (!select_chmap(ao, &map))
goto unlock_and_fail;
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)))
goto unlock_and_fail;
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);
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)
goto unlock_and_fail;
/* Wait until the stream is ready */
2012-03-24 15:28:38 +00:00
pa_threaded_mainloop_wait(priv->mainloop);
2012-03-24 15:28:38 +00:00
if (pa_stream_get_state(priv->stream) != PA_STREAM_READY)
goto unlock_and_fail;
2012-03-24 15:28:38 +00:00
pa_threaded_mainloop_unlock(priv->mainloop);
2012-03-24 15:28:38 +00:00
return 0;
unlock_and_fail:
2012-03-24 15:28:38 +00:00
if (priv->mainloop)
pa_threaded_mainloop_unlock(priv->mainloop);
fail:
if (priv->context) {
if (!(pa_context_errno(priv->context) == PA_ERR_CONNECTIONREFUSED
&& ao->probing))
GENERIC_ERR_MSG("Init failed");
}
if (proplist)
pa_proplist_free(proplist);
2012-03-24 15:28:38 +00:00
uninit(ao, true);
return -1;
}
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)
GENERIC_ERR_MSG("pa_stream_cork() failed");
}
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) {
GENERIC_ERR_MSG("pa_stream_write() failed");
len = -1;
}
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);
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)
{
// 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)
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);
}
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);
}
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);
}
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;
}
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))) {
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);
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);
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;
}
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;
}
2012-03-24 15:28:38 +00:00
/* A callback function that is called when the
* 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;
if (is_last < 0) {
GENERIC_ERR_MSG("Failed to get sink input info");
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);
}
static int control(struct ao *ao, enum aocontrol cmd, void *arg)
2012-03-24 15:28:38 +00:00
{
struct priv *priv = ao->priv;
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))) {
GENERIC_ERR_MSG("pa_stream_get_sink_input_info() failed");
2012-03-24 15:28:38 +00:00
return CONTROL_ERROR;
}
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 =
VOL_PA2MP(pa_cvolume_avg(&priv->pi.volume));
2012-01-17 06:55:04 +00:00
else {
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;
}
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;
pa_cvolume_reset(&volume, ao->channels.num);
2012-01-17 06:55:04 +00:00
if (volume.channels != 2)
pa_cvolume_set(&volume, volume.channels, VOL_MP2PA(vol->left));
2012-01-17 06:55:04 +00:00
else {
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);
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);
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;
}
}
2012-03-24 15:28:38 +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,
.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
};