On 10/6/06, Clemens Ladisch <[EMAIL PROTECTED]> wrote: > Except when doing input. In ALSA, we just call them xruns. :-)
Yes, that is the better term.. I should be using it. > All three choices are possible, depending on how the application has > configured the device. Either application xruns get ignored, in which > case snd-usb-audio will continue submitting URBs from its completion > handlers, or the stream will be stopped (and then must be explicitly > restarted, and that can fail for various reasons). ...that was only two options :-) But if my choice is "I never know anything went wrong" or "You get errors but cannot recover from them", I'm not going to choose. Neither choice is acceptible. The problem in some ways is specific to USB and the way budgeting happens. If an ISOC stream loses its bandwidth allocations, it may not be able to get it back because of bandwidth fragmentation. On, eg, an eMagic eight-channel box running at 24/48, bandwidth fragmentation means you will never be able to recover from a stream shutdown without first also shutting down everything else using USB, and starting everything up in sequence from the beginning. This is because FS audio devices are pushing bandwidth limits. > With the current API, the only reliable way of detecting a stopped > stream is indeed the absence of resubmits from the completion handlers. Is this actually desirable, or just the way it currently is? 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
