On Mon, 9 Oct 2006, David Brownell wrote: > > > > I don't like the idea of having two separate pathways for reporting the > > > > same kind of error. If one reporting technique is reliable and another > > > > isn't, why keep the unreliable one? > > Both mechanisms being dicussed are reliable within their domains.
That's a very wishy-washy comment. "This technique doesn't always work, but whenever it does work it is reliable." > > What difference does it make? What are you going to differently, knowing > > that an underrun is happening right now (and started in the very recent > > past) as opposed to knowing that an underrun started 2 ms ago (and may > > already have gotten caught back up)? > > If a submit-time underrun notification says "you underran by <this much>", > it's at least theoretically possible to skip forward that much in the > output stream ... minimizing _wasted_ work, and helping turn those faults > into pure dropouts rather than delayed/out-of-phase sound/video. The lengths of underruns are generally biased toward low numbers, right? The most common length is 0 (no underrun), and the next most common is 1 slot. Now I don't have hard numbers to support this, but I rather suspect that the amount of work involved in returning an error code and then doing a special jump forward by 1 slot is more than the amount of work involved in simply accepting the data, queuing it uselessly, and blindly moving on. In any case, missed slots do _not_ turn into delayed/out-of-phase data. They are just missed, or as you say, pure dropouts. > I don't know that Linux makes use of the explicit feedback channel that's > implemented by interrupt transfers going the opposite direction to the > ISO transfers, but such mechanisms are certainly spelled out in the USB > spec ... and they clearly spend extra processing to achieve more accurate > synchronization. I'm not sure what you mean. The only synchronization mechanism I remember in the USB spec has to do with synchronizing the clocks of multiple host controllers. That's not directly related to what we're discussing... Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel