On Thu, 5 Oct 2006, Christopher "Monty" Montgomery wrote: > > No, that's not what I said. The way it's supposed to work is like this: > > The bandwidth is released as soon as the last completion handler callback > > returns, which has nothing to do with whether or not an overrun occurred. > > Are overrun and underrun synonyms here?
Sorry, a persistent thinko. s/overrun/underrun/g. > What happens when, eg, an application does not submit more audio to > the usbaudio layer in time to avoid an underrun in playback? In that > case, all the completion handlers would return and the stream would be > released. I don't know the details of how usbaudio works. If it suffers an underrun from an application, it has a choice: submit meaningless URBs -- silence, or repeat the previous data -- or lose its bandwidth reservation. > > An overrun occurs when the completion handler fails to submit an URB in > > time for its slot. But as long as the completion handler submits any URB > > at all, it isn't the _last_ callback and so the bandwidth is not released. > > Ah, so if, eg, usbaudio has no more playback data to submit, blank > URBs are supposed to get filled in? I'm trying to understand what is > supposed to happen, and how that differs from what previously and > currently happens. Basically yes. Although if the driver doesn't mind losing its reservation, the blank URBs aren't necessary. The bandwidth will be reserved again when submission restarts, assuming it is still available. > > I don't know the details of how ehci-hcd used to implement this. But > > waiting until endpoint_disable is wrong. > > endpoint_disable is where the budget is released, which has > little/nothing to do with the hardware schedule itself. Once a USB > periodic endpoint is open()ed, it must be guaranteed to be schedulable > until it is close()d. The USB drivers don't have a strong notion of endpoints being opened or closed. They are "opened" on demand, when an URB is submitted, and they are "closed" when the endpoint's queue drains completely. To the extent that these notions make sense, i.e., those times are when bandwidth is reserved or released. There is no separate API for explicitly "opening" an endpoint or reserving bandwidth. > OK, I think here may be a point of confusion. A URB has no specific > slot[s] until it is submitted. The endpoint, as a whole, has a > circular, infinite set of guaranteed available slots URBs can be > dropped into, therefore it is not possible to miss 'all the slots' (in > the old scheduler, bandwidth allocation was not circular). A URB is > associated with no specific point[s] in time (or the schedule) until > ehci_urb_enqueue, but so long as there's a budget, enqueue is > guaranteed availability of slots. Right. Notice that so long as the queue on a periodic endpoint doesn't drain completely, drivers shouldn't try to submit URBs for particular slots. The assignment of slots is up to the HCD; normally each URB will get the slot after the end of the previous URB. When an underrun occurs the HCD might or might not choose to assign the URB to slots that have already expired. As far as I know this decision has not been specified anywhere. > Unless, of course, the URB is so large as to overflow the entire > schedule, in which case it is refused. But that's not what we're > talking about. Agreed. > > Missing schedule slots because an URB was submitted too late should not be > > enough to release the bandwidth reservation. That should happen if and > > only if the stream is broken, that is, if no more URBs are queued for the > > endpoint when a completion handler returns. > > OK, this makes clear another point of confusion. What exactly do you > mean by 'completion handler'? sitd_complete et al? >From your point of view, completion handlers are calls to usb_hcd_giveback_urb(). > And by 'the > completion handler submitting a new URB', you mean draining the > internal queue of a higher level driver, eg, usb-audio? What if the > source of latency is the application, not the driver? If the application is causing difficulties, the higher-level driver has to cope one way or another. > 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. > 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. 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
