On Thu, 5 Oct 2006, Christopher "Monty" Montgomery wrote:

> On 10/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> >> The intent is that endpoint_disable is called upon close(); in my
> >> testing (and from the code I read), close would in fact always result
> >> in an endpoint_disable.
> >
> > No, it doesn't.  endpoint_disable() happens only at a few specific times:
> > when an altsetting or configuration is set or when the USB device is
> > unregistered.  Of course, if usbaudio decides to call usb_set_interface()
> > whenever its device file was closed then you would be okay.  However
> > bandwidth release shouldn't rely on behavior like that.
> 
> My intent was that it be tied to close(), and if it is not, then yes
> that's an error.  OTOH, it's still a better situation that living in
> constant dread of the whole house of cards crashing down with a sudden
> -ENOSPC.

But close() goes to the higher-level driver, which has no direct way of
informing ehci-hcd that the endpoint is closed since that notion isn't
part of Linux's USB API.  All it can do is tell ehci-hcd that it isn't 
using the endpoint any more, by allowing the queue to drain.

> Is there any mechanism for tying this to close()?

No.  And there doesn't need to be.

>  I *must* be able to
> trust that an isoch stream will not randomly crash and burn
> unrecoverably.  A stutter is bad enough, but having the only underrun
> behavior be 'Oops!  Sorry!  You lose!' is not acceptable, and I don't
> care how 'correct' it is to have a whole troupe of people unhappy with
> me for the sound hardware failing again.  We may be amateurs, but
> we're pretty darn serious.

It's entirely up to the higher-level driver.  If that driver is written 
correctly it will keep the queue filled and the stream will remain 
uninterrupted.  If you *must* be able to trust your streams, talk to the 
driver's maintainer (Clemens) -- don't change ehci-hcd.

> > > I do not want any possibility of bandwidth being released prior to
> > > close() in the event that the source of the underrun is the
> > > application, not just latency internal to the kernel.
> >
> > Then usbaudio has to submit URBs even when no data is available.
> 
> Failure will still occur when the kernel is the source of the latency.

No it won't.  Why should it?

>  In my primary use case, the endpoint will lose its bandwidth
> reservation,

What makes you think that?

> and it will not get it back (due to bandwidth
> fragmentation; remember, I'm pushing theoretical limit across six
> endpoints per TT).  That is a monumental disaster on the scale of the
> entire theater losing power.  The response to a minor failure should
> not be 'become a major failure'.  An isoch stream is all about
> bandwidth guarantees, and tearing it down on a minor hiccup works
> against the whole point.
> 
> In other words, what is 'correct' is just punishing the users in practice.

You still don't seem to understand.  Kernel latency by itself _cannot_ 
cause a bandwidth reservation to be lost.  Only the higher-level driver 
can do that, by failing to keep the URB queue non-empty (i.e., by failing 
to resubmit within its completion handler).

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