On Tue, 20 Oct 2009, Clemens Ladisch wrote: > Steve Calfee wrote: > > This is the problem. It completely violates the definition of > > isochronous. Periodic endpoints are guaranteed bandwidth and > > timeliness. There is no guarantee about delivery - in fact iso is not > > guaranteed to be delivered safely at all. Inserting big gaps in a > > transfer because of unrelated processor loads or chip bugs is wrong. > > If an app needs guaranteed good data, it should not be using iso > > transfers. An app that needs delivery guarantees should use bulk or > > maybe high bandwidth interrupt transfers. > > > > I think you should mark the missed transfers as failed and just skip > > them. This would maintain the "chronous" aspect of the transfers. > > Delaying 80 uframes means delaying up to 80*1024*3=245760 bytes that > > were supposed to be timely on isochronous transfers. FS audio delays > > of 10 msec is very irritating and noticable. > > For the audio drivers, throwing away some data is better than time- > shifting. With the current patch, the only way to implement correct > behaviour would be for the driver to check the actual start frame after > the URB has been submitted, and, if the HCD has introduced a gap, kill > all URBs, throw away 10 ms of data, and resubmit the following data. > > Furthermore, there are devices where multiple isochronous streams must > be synchronized. > > > Alan made a comment about excepting the ASAP scheduling, but since > > that is the only practical scheduling method for applications, I think > > all missed schedule windows should just be returned as "done" with an > > error per iso packet transfer within the urb. > > Or at least this behaviour should be selectable with a flag (ASAP or > !ASAP or some new one). I agree, this needs to be fixed. But it is a separate issue, so it should be fixed in a separate patch. Sarah, I can work out a patch that handles this first; then your IST can go on top of it. How does that sound? 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