On Fri, Sep 7, 2012 at 11:44 PM, Alan Stern <st...@rowland.harvard.edu> wrote: > On Fri, 7 Sep 2012, Peter Chen wrote: > >> > >> > 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. >> > >> Can I understand this problem like below: >> >> It is OUT ISO transfer, at each completion handler, it prepares >> 4 iTDs for 4 packets. >> >> When the above problem occurs, the class driver will submit packet >> from 5 - 48, and the controller driver will prepare 44 iTDs. (or the class >> driver still submits packet 5-8?) > > The class driver submits packets 5-8, because each time the completion > handler runs it prepares 4 iTDs. > >> 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? And what will happen when the thing goes to wrong? > Alan Stern > -- 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
