Date: Wed, 14 Nov 2012 21:16:35 +0900 (JST) From: SAITOU Toshihide <toshi@ruby.ocn.ne.jp> To: hselasky@c2i.net Cc: freebsd-usb@freebsd.org Subject: Re: isochronous transfer packet is out of sequence Message-ID: <20121114.211635.122622657.toshi@ruby.ocn.ne.jp> In-Reply-To: <201211131744.11220.hselasky@c2i.net> References: <201211131452.16508.hselasky@c2i.net> <20121114.002306.36926536.toshi@ruby.ocn.ne.jp> <201211131744.11220.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <201211131744.11220.hselasky@c2i.net>
Hans Petter Selasky <hselasky@c2i.net> writes:
> On Tuesday 13 November 2012 16:23:06 SAITOU Toshihide wrote:
>> In message: <201211131452.16508.hselasky@c2i.net>
>>
>> Hans Petter Selasky <hselasky@c2i.net> writes:
>> > On Tuesday 13 November 2012 14:26:52 SAITOU Toshihide wrote:
>> >> In message: <201211121342.47141.hselasky@c2i.net>
>> >>
>> >> Hans Petter Selasky <hselasky@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121114.211635.122622657.toshi>