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>
