On Tue, Oct 20, 2009 at 09:53:59AM -0400, Alan Stern wrote: > 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? Yes, that sounds fine. At least this code is getting looked at. :) Sarah -- 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
