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

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

 



>>>> If the feedback is supported, the device will know host sends data slowly,
>>>> it will give speed up feedback information after it receives packet 5 or other
>>>> packets depends on its interval at descriptor. At this information, it can tell
>>>> the host to increase the packet size, then the transaction length and
>>>> transaction
>>>> numbers at iTD can be increased(Assume it was not maximum).
>>>
>>> Clemens pointed out that this won't work if the delay is too long.
>>
>> Clements said "In such a situation, the delay is much bigger than the
>> device's buffer,
>> so just sending more samples afterwards will not help." before.
>>
>> I don't understand what will not be helped?
>
> The frequency feedback mechanism is designed to compensate for small
> differences in the host's and the device's clocks; it is not suitable
> for situations where the host sends less data than it should (or none
> at all).  Devices have a buffer that is no larger than two or three
> milliseconds.  Furthermore, the maximum packet size usually is only
> about 10 % larger than needed for the nominal sample rate, so it would
> in no case be possible to compensate for even a single lost packet.
>
>
OK, if host takes responsible for re-sync the data,
- When and where the class driver knows out-of-sync? At completion
function? It may
also several milliseconds later than last packet.
- How to compensate the data which is out-of sync quicker than feedback way?

> 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