[pulseaudio-discuss] underrun behavior with alsa-plugins

[David Henningsson]

On 2011-04-19 18:12, Maarten Lankhorst wrote:
> Hi all,
>
> For wine I was investigating a bug with pulseaudio, it seems
> alsa-plugins' pulse driver ignores underruns.

Hmm, doesn't wine come with a native pulse driver these days?

> This is probably because
> an underrun will force you to call snd_pcm_prepare, this will destroy
> the stream and set up a similar new one again.

...whereas the proper way to resolve the underrun in the pulse plugin is 
just to feed it with more data, which is likely what would happen if you 
do not report the underrun.

> This causes more
> susceptibility to underruns, so that code was disabled.

Takashi added some kind of option so you can turn the reporting of 
underruns on again, if that helps.

> However if I
> force underruns to occur,the state will stay running and it appears
> there is still some data left in the buffer, so sound stalls entirely.

This is nothing I've heard of.

> The latency gets updated to something like 0x7bdXXXXXXXXXXXXX which
> looks suspiciously much like a pointer to me, which may be a bug. If I
> instead make pulse_prepare call pulse_start on underrun, it's handled
> properly and sound will continue to work.
>
> So my questions are.
> 1. Is the weird latency value update a bug?

I guess so, but what sense would it make to read the latency if you're 
in an underrun condition - and btw, exactly what latency variable is this?

> Digging it up I can only
> assume it's a bug in src/stream.c , but I haven't figured out why yet.
> Tested with pulseaudio.c
> 2. Any comments on this patch for alsa-plugins?

IIRC, by setting handle_underrun to 1, you're reopening bugs of 
broken/skipping audio for mpg123 and other programs, which get stuck in 
an infinite loop of "write one sample, force start the stream, write 
more samples, asynchronusly get an underrun, drop the stream and drop 
samples already written".

There should be threads on at least alsa-devel about this, from a year 
back or so.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic