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