On Mon, 3 Sep 2012, Clemens Ladisch wrote: > Alan Stern wrote: > > How should the lower USB layers handle delays in transferring > > isochronous data? [...] 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? > > The ALSA API promises that the samples in a stream run at a fixed clock, > i.e., samples are never delayed or accelerated. > > > 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. > > This would not be acceptable; future samples must be scheduled for the > same frame for which they would have been scheduled without the delay. I suspected as much. It's good to have the suspicions confirmed. > > 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. > > Both would be possible. At the moment, a submission failure would cause > the driver to stop the stream and report an error to the application. A submission failure is cleaner than an immediate completion, because we could then avoid making a whole series of doomed submissions (and using up a lot of stack space). On the other hand, it would be necessary to tell the client how many slots have to be skipped. Any idea how to do that? And of course, it would be necessary to change the clients to take this new information and new failure mode into account. > In this kind of situation (where it's known that multiple packets have > not been transferred), it would be somewhat preferrable to report the > error instead of ignoring it. That's a good idea. I can add a warning message to ehci-hcd. Should it trigger when any packets have been skipped, or only when the number of skipped packets is so large that an entire URB has to be rejected? > > 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. > > Yeah, "schedule directly after the previous packet, or fail" and > "schedule for the next possible frame" might be useful. (But the > audio driver would always use the first option.) I'll use URB_ISO_ASAP to mean "the next possible slot". Leaving that flag turned off will mean "the slot after the previous packet". I can do this for ehci-hcd, ohci-hcd, and uhci-hcd. I don't know if xhci-hcd will be able to support this, however. 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
