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

Reply via email to