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

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

 



Alan Stern wrote:
> On Mon, 3 Sep 2012, Clemens Ladisch wrote:
>> Alan Stern wrote:
>>> Alternatively, the host controller driver could fail the next 40 ms
>>> worth of isochronous URBs, so that the higher-level client catches up
>>> to where it should be.  The failure could occur during submission, or
>>> the URBs could be accepted and then forced to complete immediately,
>>> with no data transferred.
>>
>> Both would be possible.  At the moment, a submission failure would cause
>> the driver to stop the stream and report an error to the application.
>
> A submission failure is cleaner than an immediate completion, because
> we could then avoid making a whole series of doomed submissions (and
> using up a lot of stack space).  On the other hand, it would be
> necessary to tell the client how many slots have to be skipped.

The audio driver wouldn't care.  Logically, it starts a new stream.

>> In this kind of situation (where it's known that multiple packets have
>> not been transferred), it would be somewhat preferrable to report the
>> error instead of ignoring it.
>
> That's a good idea.  I can add a warning message to ehci-hcd.

I meant report to the client as an error, instead of silently dropping
packets.


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


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

  Powered by Linux