In message: <201211131744.11220.hsela...@c2i.net> Hans Petter Selasky <hsela...@c2i.net> writes: > On Tuesday 13 November 2012 16:23:06 SAITOU Toshihide wrote: >> In message: <201211131452.16508.hsela...@c2i.net> >> >> Hans Petter Selasky <hsela...@c2i.net> writes: >> > On Tuesday 13 November 2012 14:26:52 SAITOU Toshihide wrote: >> >> In message: <201211121342.47141.hsela...@c2i.net> >> >> >> >> Hans Petter Selasky <hsela...@c2i.net> writes: >> >> > On Monday 12 November 2012 12:52:08 SAITOU Toshihide wrote: >> >> >> I have tryed the USB isochronous transfer for UVC cam using libusb >> >> >> interface and I find the packet fragment is out of sequence on the >> >> >> FreeBSD(1). But I don't find it on the MacBook(2). >> >> >> >> >> >> (1) FreeBSD 9.1-RC2, Intel Core i7 3770T >> >> >> (2) Mac OS X 10.6.8, Intel Core 2 Duo, libusb 1.0.9 (single core) >> >> >> >> >> >> Can I prevent this behaviour using libusb interface or is >> >> >> this an expected behaviour? >> >> >> >> >> >> The bellow I issued two libusb_submit_transfer at the beginning. > > Hi, > > There are some internal limits, maybe not visible directly at libusb level. > > The host hardware usually does not handle more than 128 milliseconds of > transfers at a time. > > You should not sumbit more frames than will be processed in (128 - 16) / 2 ms > at any time. For HighSpeed with fastest interval you will need around 8*2*56 > ms worth of frames, which is the maximum supported. > > grep -r USB_MAX_FS_ISOC_FRAMES_PER_XFER /usr/include > grep -r USB_MAX_HS_ISOC_FRAMES_PER_XFER /usr/include > > Webcamd has patches for the Linux code, to fix this issue.
Ah! I took it for granted that PKTS_PER_XFER 0x80 is safe to compared with usbdump of the webcamd. I was biased, my bad, sorry. Finally PKTS_PER_XFER 0x40 is perfect with my fixed callback function. (128 - 16) / 2 = 56 16 : maximum number of control request? (*1) 2 : two transfers 56 frames plus 2+8 frames (repayment of (*1) for fastest interval?) = 66 64 (0x40) is nearest multiple of 8 I only have a differences compared with my MacBook is the device closing behaviour. It looks like the device stays in STREAMING state after exiting. libusb_reset_device and using signal trap may be needed. Thank you very much! --- SAITOU Toshihide _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"