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). Best 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
