On Wed, 19 Sep 2012, Laurent Pinchart wrote: > To be honest I thought the ASAP flag did what it now does with your patch :-) > The uvcvideo driver doesn't care much about when URBs will be transferred, I > just set the frame number to 0 and set the ASAP flag. > > If the number of lost packets is small enough, the video driver can get > > it directly by looking at the status fields in the isochronous packet > > descriptor structures. If the number is too big, though, it won't be > > reported at all -- the driver will know only that a big gap occurred. > > From what you say, this would be okay. > > Using timestamps the lost frames can be detected, assuming the frame rate is > constant. With a variable frame rate we're probably screwed. All right. It sounds like as far as uvcvideo is concerned, recovering video-in frame synchronization after a drop-out doesn't matter very much. You don't much care if some of the frames are gone from the data stream with no indication as to how many were skipped over. Or if you do care, you don't think there's much to be done about it. (The expected length of these drop-outs is not likely to be much more than 100 ms. At reasonable video frame rates, that's not going to amount to more than a few frames.) > > The best solution may be, if an URB submission fails with a -EXDEV error, to > > move forward to the next video frame boundary and restart transmitting from > > there. Depending on the protocol, you might want to delay the next URB > > submission so that the device doesn't see two frame boundaries too close > > together. Either way, you would set the URB_ISO_ASAP flag for the first URB > > and leave it turned off for all the following URBs. > > I'm not sure to get that. Why should it be turned off for the following URBs ? Because if the ASAP flag is turned on, you won't be notified about large gaps in the data stream. Maybe you don't care about this; I suppose the proper action would depend in part on how the device reacts to the missing data. Here's a simplified example to illustrate the point. Let's label the data packets you want to send as A, B, C, and so on. You transmit A, B, C, and D. Then there's a large gap, during which the device expects to receive E and F, but nothing actually gets sent. After the gap, if USB_ISO_ASAP is set then the driver would be unaware that anything went wrong. The computer would end up sending: A B C D . . E F G In other words, all the packets from E onward would be sent later than they should have been. On the other hand, if you turn off URB_ISO_ASAP for all the packets besides the first, then after the gap one of two things would happen (depending on the big the gap is compared to the depth of your isochronous queue). The first possibility is that packets E and F would be ignored, so you would end up transmitting: A B C D . . G H I There's still a gap but now the later packets are sent at the right times. The other possibility is that the usb_submit_urb() call for packet E would get an error. The driver would then recognize that something had gone wrong and it would try to recover, perhaps by jumping forward to the next video frame boundary and setting URB_ISO_ASAP for the next packet. > > Basically what I'm asking is whether the API described in the documentation > > RFC (http://marc.info/?l=linux-usb&m=134382746009339&w=2) > > That's "[PATCH] usb: storage: stop all current urbs when device is > disconnected". I'm pretty sure you meant something else :-) Weird copy/paste error. Pretend that I wrote what I meant instead. :-) Alan Stern -- 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
