On 10/6/06, Clemens Ladisch <[EMAIL PROTECTED]> wrote: > In the case of ALSA, it's the application's choice whether an underrun > should stop the stream.
Yes, I agree the application should have such a choice. I had noticed, though, that I either never see underruns, or when an underrun happens, the stream dies and I cannot restart it (snd_pcm_prepare always fails after an EPIPE). > I don't know which application you were using, Beaverphonic and rtrecord, which I wrote. They're realtime apps and essentially treat the machine as a dedicated applicance while running. > but in the case of Jack, it was decided that it would be better to > have the stream stopped so that the xrun can be detected and reported > instead of having an unexplained (or worse, undetected) stutter. I agree, it's important to report the error. The problem is that in the current setup, the act of reporting the error also exacerbates it (making recovery potentially impossible). I want very much to give us a way to do both (report the error and recover gracefully). It's imperative a USB isoch stream not be released on xrun if you want to be sure you can recover. Monty ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
