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. > 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. 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. > 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.) Regards, Clemens -- 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
