On Sunday 08 October 2006 4:51 pm, [EMAIL PROTECTED] wrote: > > When sample and playback are lockstep (read 64 samples, process, write > them for playback, read next 64 samples, process, write them for > playback), we will only ever be one URB deep.
Can't be guaranteeed. Never use less than two URBs for ISO streams. > There will never be > another URB waiting. So, every read and every write will complete the > 'last' URB and shut the stream down. That's not the intended behavior though; call it an artifact of the early implementation shortcuts, in particular not having a proper schedule tree. Given such a schedule it would be clear that until the handler _returns_ from that "last" URB without submitting any replacement URB, that endpoint is still in the schedule; bandwidth is still reserved. > Not only does that force > rescheduling, but it also means that due to the SLOP, it could not > possibly be scheduled for the next slot. There would always be a gap. The gap is inherent in having let the stream empty. Once that happens, given IRQ latencies there aren't many good controls over how much of a gap exists. The original notion of SLOP would not have kicked in there ... if your patches added it, yes that would make extra trouble. But the root cause is still that streaming ISO with just one URB is not a viable approach ... the driver on top of usbcore was doing the wrong thing. - Dave ------------------------------------------------------------------------- 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
