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? We could pretend nothing happened and continue to handle URBs normally, scheduling each submission for the next available slot. But for an isochronous-OUT transfer, this would mean that all the future data values are delayed by some 40 ms relative to the earlier data. If another glitch occurs then the following data will be delayed by even more. For some applications this might not matter, but for others (real-time things like voice) it could be quite bad. Similar problems arise with IN transfers. Alternatively, the host controller driver could fail the next 40 ms worth of isochronous URBs, so that the higher-level client catches up to where it should be. The failure could occur during submission, or the URBs could be accepted and then forced to complete immediately, with no data transferred. What's the right thing to do? My feeling is that the behavior should be decided not by the host controller driver but rather by the higher-level client. We could use the URB_ISO_ASAP flag for this purpose -- right now it is essentially useless. Or maybe we should do something else I haven't thought of. What would be the best approach for your purposes? 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
