PulseAudio backend causes server to underrun in some configurations #45
Comments
|
I'd like to add I've been fighting this to over on the Arch Forums. https://bbs.archlinux.org/viewtopic.php?id=239932 |
|
Dear specialists, |
|
Hello, |
speech-dispatcher requests a total latency of 1 ms, which in turn gives sub-ms latency inside the PulseAudio engine. This causes unnecessary CPU consumption, or underruns. I understand that you would want immediate feedback, but 20 ms seems more reasonable. Fixes brailcom#45
speech-dispatcher requests a total latency of 1 ms, which in turn gives sub-ms latency inside the PulseAudio engine. This causes unnecessary CPU consumption, or underruns. I understand that you would want immediate feedback, but 20 ms seems more reasonable. Fixes #45
|
(FTR, we do want a small buffer to get reactivity from desktop action to speech feedback) |
|
speech-dispatch still causes audio disruption for me for all applications on an ALC1220 using PA |
|
@nifker could you get verbose PulseAudio server logs from when you do this? If it is with recent speech-dispatcher with @sthibaul's fix, please file a bug on https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues |
I ran into this while investigating Firefox bug 1444567: on some systems, speech-dispatcher's PulseAudio backend causes the PA server to reconfigure itself for a latency so low that it causes audio in other applications to continuously underrun, effectively breaking normal audio playback.
speech-dispatcher's PA backend configures a 100 byte pa_buffer_attr.tlength here:
https://github.com/brailcom/speechd/blob/master/src/audio/pulse.c#L131
This seems strange - aside from being incredibly small (most systems can't reasonably service a sub-millisecond latency stream), PA expects a computed byte value, but speech-dispatcher's code doesn't account for sample rate, channel count, or sample format changes. For a typical 44.1kHz stereo f32 stream, a 100 byte tlength ends up requesting a 270 microsecond buffer.
Because this pa_buffer_attr is passed to pa_simple_new, there's no opportunity to pass specific pa_stream_flags_t values. The defaults for pa_simple_new include PA_STREAM_ADJUST_LATENCY, which I understand is what causes the server to reconfigure to service the requested latency rather than simply letting the stream's latency float up to the server's normal value.
It seems like speech-dispatcher's PA backend should request a more realistic latency value and scale it correctly for the requested sample rate, channel count, and sample format. What would break if tlength were set to -1, as the other pa_buffer_attr fields are? If the intention of low latency streams is to avoid losing buffered audio, the correct solution is to use pa_simple_flush (or, if that doesn't work, a timer to wait for the buffer to flush).
It's not clear what hardware/software/configuration combination causes the PA server to enter this state. On my Fedora 27 system, I can see speech-dispatcher connecting to PA and requesting unusually low latency streams, but it doesn't cause the PA server to behave badly. On other systems, such as the user's in the Firefox bug and the other cases I've linked below, PA ends up in a bad state until speech-dispatcher is killed or PA is restarted (effectively disconnecting the s-d streams). So there's possibly a component a PA bug or misconfiguration at play too.
This has also turned up in other applications, e.g. Mumble and for an Ubuntu user.
CCing @ford-prefect as a PulseAudio expert in case he has any input on this.
The text was updated successfully, but these errors were encountered: