On Mon, 9 Oct 2006, Christopher "Monty" Montgomery wrote: > > > 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. > > 2ms of read URB + 2ms or write URB is 4ms, which is already eating > most of our turn-around time just in buffering. > > > 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.
It's amusing watching the two of you talk past each other... especially in regard to issues of latency. 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. 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. 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. In addition, there are two important problems not mentioned above: The first has to do with the order of the callbacks. Although I wrote step E after step D, there's no reason they can't occur in the opposite order. When that happens the driver will be in trouble because the data for E's submission won't be available yet. The driver could submit dummy data, but that's foolish given that step D will happen in the very near future. Or the driver could submit nothing until step D occurs, which would cause the endpoint queue to dry up and the bandwidth to be deallocated. This is precisely why Monty wants to allow allocations to survive for some period even with no URBs in the queue. The second difficulty has to do with kernel latency. Suppose for one reason or another the system is busy, and consequently step E doesn't occur until after frame 3 has already begun. It wouldn't take much of a delay, and according to Dave a 1-ms IRQ latency is to be expected every now and then. The only way to survive without a dropout is to have an extra URB in the write queue. That will give an additional millisecond of breathing space, at the cost of increasing the microphone-to-speaker delay by 1 ms. 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? (It's worth pointing out that this analysis doesn't mention the depth of the read queue. It doesn't matter how many URBs are waiting in that queue; all that matters is how much data each URB can receive.) 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