Alan Stern wrote: > On Thu, 18 Jul 2013, Ming Lei wrote: >> On Thu, Jul 18, 2013 at 3:24 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
