On 10/6/06, Alan Stern <[EMAIL PROTECTED]> wrote: > On Fri, 6 Oct 2006, Clemens Ladisch wrote: > > In the case of ALSA, it's the application's choice whether an underrun > > should stop the stream. I don't know which application you were using, > > 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. > > Would it be better to add a way for the kernel to inform the application > that an xrun occurred? Although I don't know how that would work...
What is wrong with returning a loss of sync condition upon next request? It has precedent. (my apps look both for xruns as well as monitor buffer depth. I've noticed that although usbaudio/ALSA are good about reporting buffer starvation, they don't report actual hardware xruns. Now I realize it's because ehci-sched had previously been incapable of noticing it). 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
