Re: [RFC] How to handle delays in isochronous transfers?

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

 



[CC'ing an USB audio heavyweight - Daniel Mack]

On Tue, Sep 4, 2012 at 12:39 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 3 Sep 2012, Jassi Brar wrote:
>
>> On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>> > Clemens and Laurent (and anyone else who's interested):
>> >
>> > How should the lower USB layers handle delays in transferring
>> > isochronous data?  I'm asking you because the most common usages of
>> > isochronous transfers are for audio and video.
>> >
>> > Here's an example to illustrate what I mean.  Typically an audio or
>> > video driver will keep a queue of around 10 ms of data submitted to an
>> > isochronous endpoint.  I have seen reports from users where URB
>> > completion interrupts were delayed by as much as 50 ms.  In one case
>> > the delay was caused by a bug in a wireless drivers that left
>> > interrupts disabled; in another case the cause was unknown -- it might
>> > have been a hardware problem.  At any rate, when this happens the
>> > endpoint's queue drains completely.
>> >
>> > Clearly this will cause a glitch in the data stream.  The question is:
>> > What should we do to recover and re-synchronize?
>> >
>> How about effectively increasing the queue length from 10ms to 50ms
>> (max anticipated latency) ?
>
> There are two problems with that approach.  First, 50 ms isn't really
> the max anticipated latency; it's merely the largest that I've seen so
> far.  (In fact, the max anticipated latency is probably < 10 ms; these
> 50-ms delays were definitely exceptional.)
>
It doesn't have to be hardcoded - maybe USB audio/video code could get
the hint via some module parameter?

> Second, people involved in real-time programming (such as audio or
> video) generally want to keep latency to a minimum.
>
If we progress the h/w pointer of ALSA ring buffer at URB completion
(and not at URB submission), this shouldn't affect the latency. And
IIRC, USB isn't anyway recommended for real-time usage.

cheers.
--
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