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. Is there any mechanism for tying this to close()? 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. > > 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. In my primary use case, the endpoint will lose its bandwidth reservation, 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. Monty ------------------------------------------------------------------------- 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
