On Tue, 10 Oct 2006, Christopher "Monty" Montgomery wrote: > > Let's consider a simple case. Suppose we're using a full-speed controller > > instead of EHCI. It's easier to analyze and more demanding. Here's a > > best-case scenario: > > > > A. During frame 0 a pressure wave strikes the microphone. The > > hardware digitizes the signal and stores the data internally. > > > > B. During frame 1 the data collected in A is sent to the host. > > > > C. At the end of frame 1 the host gets a transfer-completed IRQ. > > > > D. During frame 2 the HCD invokes the read URB's callback. The > > audio driver and application massage and re-buffer the data for > > retransmission. > > > > E. Then the HCD invokes the callback for an old write URB. The > > audio driver resubmits, using the data generated in step D. > > > > F. The HCD takes the submitted URB and schedules it for frame 3. > > I will point out that it's possible (I know that's not how linux does it): > > The read completes in frame 1 and the URB callback is called before > frame 1 ends. The processing of the audio happens immediately enough > to make it available for a slot in frame 2. This would assume one or > both of more aggressive completion handling and/or coupling read and > playback URB handling... which low-latency software would be doing in > userspace anyway; read/write are lockstep (I don't know of an OS that > does it that way internally though. I believe MacOS just > special-cases scheduling and completion handling).
You're talking about detecting URB completion before a completion IRQ arrives. In other words, polling. I would prefer not to see that added to the HCDs, but it is a possibility. > > G. During frame 3 the data is sent to the speaker device. > > > > H. During frame 4 the speaker plays the data out into the air. > > Given isoch and the design of low-latency devices, I wouldn't be > surprised if devices designed for low latency aren't already playing > the data in frame 3 of your scheme, as the samples pour in. The packet transfer may occur anywhere during the frame; the device would not be able to count on the data being available in time to play when the frame begins. I suppose it could start playing the data a short time before the end of the frame, though; if the packet is going to arrive at all then it has to arrive before the frame ends. > But yes, I see this example as a clear illustration of how Linux is > doing things. Nothing in the example was specific to Linux. Any OS has to work more or less this way. > > Even with no problems and 0 interrupt latency, there's still a 4-ms delay > > between the microphone and the speaker. With EHCI this can be reduced > > somewhat; you could ask the controller to generate IRQs every 0.5 ms > > instead of every ms and thereby reduce the delay to 2 ms. This quickly > > leads to diminishing returns, however, because of all the overhead > > involved in processing IRQs, invoking callbacks, etc. > > I will point out that low latency applications generally consider the > machine to be an embedded appliance. They own the box. This is > accepted. If they own the box then they also own the OS. Under Linux the only way to achieve that is single-user mode. Even then, the HCD would compete for processor time with the disk I/O routines. > > Perhaps not coincindentally, it turns out that the solution to the second > > problem also solves the first problem. If you're working with low-latency > > EHCI then the overall delay goes up from 2 ms to 3 ms. Isn't that still > > low enough to be usable? > > Usable? Oh, yes. But I'm striving for 'doing as good a job as other > systems that have been around for a while'. I'm not striving for > mediocrity. I accept it will not happen all at once (and settling the > XRUN reporting channel is higher priority and has greater practical > significance). I would also take a reliable 5ms over '2ms that > hiccups once a day' without thinking twice. Make up your mind. Do you want "as good as other systems that have been around a while" or do you want "a reliable 5ms"? The two are not obviously compatible. Alan Stern ------------------------------------------------------------------------- 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
