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