On Fri, Jul 19, 2013 at 1:44 AM, Clemens Ladisch <[email protected]> wrote:
> Alan Stern wrote:
>> On Thu, 18 Jul 2013, Ming Lei wrote:
>>> On Thu, Jul 18, 2013 at 3:24 AM, Alan Stern <[email protected]>
>>> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
