[pulseaudio-discuss] underrun behavior with alsa-plugins

[Maarten Lankhorst]

Hey,

Op 20-04-11 15:18, David Henningsson schreef:
>>>> 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.
>> Sadly all too common here, if I feed data and it underruns, it may
>> appear to be running but is stalled entirely.
>
> Could you provide a test case where this occurs? (Pulseaudio/ALSA
> version, client applications/libraries, etc)

Well this could be a basic test version I suppose, although it's not 
fair since it's guaranteed to underrun and doesn't work with dmix since 
it specifies period sizes exactly.

>>>> 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.
>> This is exactly what my patch was addressing, I was fixing that bug by
>> handling underrun correctly. snd_pcm_prepare() is called when an
>> underrun occurs, so instead I make it only restart the stream if
>> underrun. Not handling underruns at all seems to allow it to stall on
>> xrun, while claiming to be running. This sometimes appears to happen in
>> other programs too though, like mplayer. Could it be because of the
>> weird latency value?
>
> Ok, thanks for the clarifications. I've taken a closer look at your
> patch now and have the following comments:
>
> When you're calling pulse_start instead of continuing in pulse_prepare -
> pulse_start will call uncork/trigger, won't that just cause another
> underrun? Would it perhaps be better to just return without doing anything?
>
> mpg123 was used as a test case for the original bug, and mpg123 calls
> snd_pcm_drop on an underrun, so you will be regressing mpg123 by
> changing handle_underrun to 1. (Now of course we could fix mpg123, but I
> don't know if there are a lot of other programs out there doing similar
> things?)
>
> My main point is that the underrun is often obsolete when the message
> reached the application, because more data has already been written,
> therefore reporting it to the app does more harm than good.
> At least until the underrun callback (and PA protocol) supports sending
> the position of underrun, together with the underrun message. If we had
> that position, we could compare that with the current write pointer to
> determine whether the underrun is actually obsolete or not.
Well, this is a dumb unfair test program that forcibly underruns, 
probably should work if you change default to hw:0, but I think dmix 
doesn't allow you to set random period sizes. If I try this with the 
pulseaudio default plugin, it will break.

With my patch:
~$ ./a.out
Written: 2047 - available: 2047
Successfully underrun
Written: 960 - available: 960
Successfully underrun
Written: 1890 - available: 1890
Successfully underrun

Without:

~$ ./a.out 2>/dev/null
Written: 2047 - available: 2047
Written: 0 - available: 0
Written: 0 - available: 0

Note: not any form of error checking is done here, just cobbled this 
dumb program together for demonstration purposes. :)

Cheers,
Maarten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.c
Type: text/x-csrc
Size: 1428 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110420/3c852d6e/attachment.c>