> > 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? > I am not sure if feedback endpoint is implemented at our ISO-transfer class driver. If it is implemented, the class driver will take responsible to speed up/slow down transferring according to the device's feedback information.
For non-supported feedback device, the device should take responsible for data loss or data too fast by changing codec clock freq or give up some data. Yes, the host controller may know if the data is really on the bus in time, and tell the class driver adjust the packet size, but device may have already changed its codec clock already or its behavior. Both host/device system high loading and clock not always the same between usb and codec at device side will cause the total payload is not the same between producer (host) and consumer (device) after sometime, so the feedback between device and host is the best way to keep data integrity. > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
