On Mon, 3 Sep 2012, Jassi Brar wrote: > On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Clemens and Laurent (and anyone else who's interested): > > > > How should the lower USB layers handle delays in transferring > > isochronous data? I'm asking you because the most common usages of > > isochronous transfers are for audio and video. > > > > Here's an example to illustrate what I mean. Typically an audio or > > video driver will keep a queue of around 10 ms of data submitted to an > > isochronous endpoint. I have seen reports from users where URB > > completion interrupts were delayed by as much as 50 ms. In one case > > the delay was caused by a bug in a wireless drivers that left > > interrupts disabled; in another case the cause was unknown -- it might > > have been a hardware problem. At any rate, when this happens the > > endpoint's queue drains completely. > > > > Clearly this will cause a glitch in the data stream. The question is: > > What should we do to recover and re-synchronize? > > > How about effectively increasing the queue length from 10ms to 50ms > (max anticipated latency) ? There are two problems with that approach. First, 50 ms isn't really the max anticipated latency; it's merely the largest that I've seen so far. (In fact, the max anticipated latency is probably < 10 ms; these 50-ms delays were definitely exceptional.) Second, people involved in real-time programming (such as audio or video) generally want to keep latency to a minimum. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
