Hi Alan, On Wednesday 19 September 2012 15:37:54 Alan Stern wrote: > 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. I care, but I don't think the USB core can provide me with any useful information. > (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. That's only a problem for video output, and the only UVC video output device I know of uses bulk transfers :-) I understand the problem though, that's something that I'll need to fix if I come across a UVC output device that uses isochronous transfers. > > > 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. :-) -- 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
