On Thu, 11 Jul 2013, Johannes Stezenbach wrote: > I took a peek at the usbmon log, and there is one thing I don't get. > > $ grep "C Zi:1:005:2" em28xx_usbmon.log | less -S > > There are several cases where the isoc descriptor actual length is > short (< 2892, e.g. 0, 552 or 1928), yet the actual_length for the > whole URB at the end of the line is still 64*2892 -- is that like it should be? Yes. When one packet is short, the following packets don't get moved up in the buffer -- their offsets are fixed in advance. The unused space at the end of the short packet remains, and it contributes to the total actual_length value for the entire URB. > Also, is it expected that the em28xx doesn't have data to send for > some microframes (for analog video capture e.g. during horizontal > or vertical blank interval)? I guess in the analyzer that should > show as an IN token with no reply instead of DATA[012] replies. Not necessarily. It might send random data, or a short (maybe even 0-length) reply. In fact, the usbmon trace does show some short packets (as you mentioned above) and even some 0-length packets. For example, see timestamp 3976305153. > Can you confirm that in the error case there is no IN token at all? That's what the analyzer log showed. Of course, it's possible that the analyzer itself was faulty, but I don't think so because Devin said the missing packets matched exactly with the corrupted data in the following microframes. > And another dumb question: Is there another USB video grabber > with different hardware which also uses isoc and works? > E.g. the cx231xx? Or do you think it might have the same missing > microframe issue but copes better with it due to larger > buffer space on the device? The uvcvideo driver works. But as you point out, the circumstances may be significantly different. 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
