Re: How should we handle isochronous underruns?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 19, 2013 at 1:44 AM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote:
> 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.

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux