On Tue, 4 Sep 2012, Peter Chen wrote: > > In such a situation, the delay is much bigger than the device's buffer, > > so just sending more samples afterwards will not help. > > > It is ISO transfer, if the delay is too much, and the buffer at device side is > empty, it is normal the screen is stopped like we watch movie on Internet > (buffering....). > > So if the delay is too much, I don't think there is a way can deal with it as > host does not send any data to device. Yes, some data is lost. We want to make sure that when the data starts flowing again, it is properly synchronized. > > Furthermore, if packets are lost, frequency feedback becomes impossible > > because the device doesn't know how many samples were lost. > Where the packets are lost? > If the packets are lost at class driver/usb driver, class driver will > know it and > should take the responsible to re-send it. > If the packets are lost on the USB bus (during the transfer), as it is > ISO transfer, > then the data should be lost, and host doesn't know the data is lost, how can > it re-sends the packet? Data should not be resent in any case. Isochronous data is never resent. Here's the problem we face: The class driver submits packets 1, 2, 3, and 4. They get sent properly, but the completion interrupt is delayed. As a result, the class driver's completion handler doesn't get called until too late; the frames for packets 5 - 44 have already expired. The data that should have been sent during those frames is lost. But the class driver doesn't know this, so when the completion handler does get called, it submits packets 5, 6, 7, and 8. They end up getting sent in frames 45, 46, 47, and 48. This means the data is now out of synchronization by 40 frames. That's the problem I want to solve. There's an equivalent problem for data flowing into the host. In this case, the URB that should have been submitted for frame 5 would receive data that the device sent during frame 45. (Whether this data contains the signals for frame 5 or for frame 45 would depend on the device; the host can't do anything about it.) Alan Stern -- 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
