Hi Alan, Sorry for the late answer, I've been travelling with no internet connection. On Tuesday 04 September 2012 10:23:41 Alan Stern wrote: > 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.) For video ISO IN problems can be split in two categories. Small delays (< one video frame) should already be properly supported as far as I can see. Data will be lost, drivers will detect that, either immediately if the protocol allows such detection, or at some video frame boundary. This will result in a corrupt video frame with missing data, and drivers will mark it as such when passing it to userspace through V4L2. Larger delays that result in completely dropped video frames can cause more serious problems. Drivers won't know how many video frames have been dropped, and the V4L2 video frame sequence number will get out of sync. Applications can work around the problem using the video frame timestamps, but that's more a hack than a proper solution. I'm not sure if there is a way to solve the problem properly. ISO IN with video typically uses the ASAP flag, and making the USB core report an artificial number of dropped ISO packets won't help much as many (most/all ?) devices transmit video frames in a variable number of ISO packets. For video output the situation is currently unclear. The only V4L2 output driver for USB devices that I know of is the uvcvideo driver, and the only UVC output device I know of uses bulk transfers. Assuming we will get video ISO OUT devices in the future, the right way to fix the problem will be to drop complete video frames on the host side if a large delays occurs. Feedback endpoints (currently not supported in the uvcvideo driver) might help (I've never worked with them, so I'd have to take a closer look). Another option would be to just check timestamps on the host side when starting a new video frame. I'm not sure whether the USB core could help with this problem. -- Regards, Laurent Pinchart -- 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
