isochronous transfer packet is out of sequence

[SAITOU Toshihide]

In message: <201211131744.11220.hselasky at c2i.net>
            Hans Petter Selasky <hselasky at c2i.net> writes:
> On Tuesday 13 November 2012 16:23:06 SAITOU Toshihide wrote:
>> In message: <201211131452.16508.hselasky at c2i.net>
>> 
>>             Hans Petter Selasky <hselasky at c2i.net> writes:
>> > On Tuesday 13 November 2012 14:26:52 SAITOU Toshihide wrote:
>> >> In message: <201211121342.47141.hselasky at c2i.net>
>> >> 
>> >>             Hans Petter Selasky <hselasky at 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