On 10/9/06, David Brownell <[EMAIL PROTECTED]> wrote: > On Sunday 08 October 2006 8:16 pm, Alan Stern wrote: > > On Sun, 8 Oct 2006, Christopher "Monty" Montgomery wrote: > > > > > > I don't know what this "low-latency" thing is you're referring to. But > > > > it sounds like it's trying to be _too_ low. > > > > > > Professional audio applications generally specify 2-5ms turnaround. > > > That's from sample to playback. More than about 5ms you can't do > > > digital monitor, realtime effects or a host of other useful things > > > sound engineers have come to expect. > > > > Okay. Then there's nothing to stop you from putting 1 or 2 ms worth of > > data in each URB and keeping 2 URBs in the queue at all times. Except > > that you run a high risk of loss-of-sync owing to kernel latency. But > > that will always be true in a low-latency application. > > Right ... Monty, remember that a millisecond of IRQ latency is very > possible, and is enough to cause an underrun if you don't have an > urb with a millisecond's worth of data running while the system hits > delays (like, another IRQ handler) before processing the previous URB.
...so there are a few things to get around. I don't actually know how Win/Mac makes it reliable, but I do know Mac special-cases low-latency in its EHCI. As for the using a single URB being an abuse of ISO: is this an abuse of ISO or an abuse of the way Linux does ISO? The first thing I thought of was that an ISO stream should not be released when the last URB completes-- it should be released when the last URB completes *after* the next scheduled slot goes past empty. We will still run into rebudgeting problems int he case of XRUN though, and we will still run into the problem of an app running happily for several hours, having an inadvertant XRUN and suddenly throwing 'ENOSPC'. Throwing ENOSPC from a previously working ISO is an abuse of the user. Any possibility of mere preemption causing an EPIPE in a successfully opened ISO stream should give you chills. We should be minimizing that possibility, not embracing it as par for the course. I understand the current design is unlikely to change, but that doesn't mean we should just accept suboptimal use cases that will come up often. 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
