Hi Alan, On Monday 01 July 2013 11:08:33 Alan Stern wrote: > On Mon, 1 Jul 2013, Laurent Pinchart wrote: > > That's correct. Unlike the UAC driver, the UVC driver doesn't care too > > much about exact timings. Avoiding packet loss is my main concern. As > > video frames are not delivered to userspace before they are fully > > transmitted, and given the large number of URBs required to transmit a > > video frame, I can submit more URBs (without reasonable limits) if that > > can help avoiding underruns. > > > > A couple of users have experienced underruns in the past due to a rogue > > driver disabling interrupts for tens of milliseconds. I don't think > > switching to tasklets will have a strong adverse effect, the 20ms buffer > > time should be large enough to avoid underruns in sane systems. > > What about error recovery for insane systems? If we do get a 50-ms gap in > the data stream, what's the best way for the UVC driver to learn this has > happens and attempt to carry on? When isochronous packets are lost video frames get corrupted. UVC doesn't provide sequence numbers for packets, so there's no way to know exactly how many packets have been lost. However, several synchronization methods are available for the driver to detect frame boundaries (namely an End-Of-Frame bit and a Frame ID bit that toggles for every frame in isochronous packet headers). The driver already handles those bits and marks video frames as complete when the EOF bit or an FID transition is detected. For uncompressed formats the driver then checks whether the received data size matches the frame size, and marks the frame as bad if it doesn't. That check can't be performed for compressed formats as the frame size is then variable. It would thus be helpful to receive a notification when a gap in the data stream is detected, through the URB status field for instance. The driver could then mark the frame being received as faulty and reset its state machine to resynchronize to the next frame boundary. -- 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