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