Re: How should we handle isochronous underruns?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux