On Fri, Jul 19, 2013 at 1:44 AM, Clemens Ladisch <clem...@ladisch.de> wrote: > Alan Stern wrote: >> On Thu, 18 Jul 2013, Ming Lei wrote: >>> On Thu, Jul 18, 2013 at 3:24 AM, Alan Stern <st...@rowland.harvard.edu> >>> wrote: >>>> On Thu, 4 Jul 2013, Alan Stern wrote: >>>>> On Thu, 4 Jul 2013, Ming Lei wrote: >>>> I had some more ideas about this. Instead of requiring drivers to set >>>> URB_ISO_ASAP on just the first URB of an isochronous stream, we could >>>> ask drivers to call usb_reset_endpoint() between streams. This would >>>> tell the HCD that the next URB marks the start of a new stream, with no >>>> need for a special flag. >>> >>> This idea still requires changes from old drivers. >>> >>> Also it might be not appropriate to call usb_reset_endpoint() in this case >>> because other host controller's implementation may do other unnecessary >>> thing for this situation. >> >> Perhaps. I doubt that HCDs need to do anything when they reset an >> isochronous endpoint, but you're right. It's safer to avoid the issue. >> >>>> Another possibility, which would be even simpler, is for HCDs to assume >>>> that if the endpoint's queue has been empty for more than 100 ms then a >>>> new stream is starting. Then drivers wouldn't have to do anything >>>> special at all. (Unless they are stopping and restarting streams very >>>> rapidly, > > ... which happens when a stream is restarted after an error, or when two > sound files are played back-to-back. The audio driver will always > explicitly restart the stream (because checking whether the timeout has > elapsed would be too much of a bother), so the timeout is not useful > in practice. > >>> In this case, we may use changing altsetting to decide start of streaming. >> >> Yes indeed. But that could still require changes to old drivers. >> >> To be even more safe, unlinking an URB should mark the end of a stream. >> That's what snd-usb-audio does when it closes a stream; it kills all >> the outstanding URBs. > > But it might be possible that the queue is empty at that point. > > > In any case, there must be _some_ mechanism to explicitly restart > a stream. I do not really care if this is some URB flag or some > function call.
Thought about the problem further, looks there is one simple approach for detecting underrun in case of empty queue: if (list_empty (&stream->td_list)) { if (running from hcd interrupt or tasklet context) underrun else new stream } Any comments on this way? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html