From owner-freebsd-usb@FreeBSD.ORG Wed Nov 14 12:40:32 2012 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B10D6FA for ; Wed, 14 Nov 2012 12:40:32 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from defer116.ocn.ad.jp (defer116.ocn.ad.jp [125.206.148.15]) by mx1.freebsd.org (Postfix) with ESMTP id 298D48FC13 for ; Wed, 14 Nov 2012 12:40:31 +0000 (UTC) Received: from msgw002-03.ocn.ad.jp (msgw002-03.ocn.ad.jp [180.37.203.78]) by defer116.ocn.ad.jp (Postfix) with ESMTP id E0BB4310027 for ; Wed, 14 Nov 2012 21:16:43 +0900 (JST) Received: from localhost (p14214-ipngn100102sizuokaden.shizuoka.ocn.ne.jp [180.51.197.214]) by msgw002-03.ocn.ad.jp (Postfix) with ESMTP id 46762A4ADAE; Wed, 14 Nov 2012 21:16:36 +0900 (JST) Date: Wed, 14 Nov 2012 21:16:35 +0900 (JST) Message-Id: <20121114.211635.122622657.toshi@ruby.ocn.ne.jp> To: hselasky@c2i.net Subject: Re: isochronous transfer packet is out of sequence From: SAITOU Toshihide 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> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 12:40:32 -0000 In message: <201211131744.11220.hselasky@c2i.net> Hans Petter Selasky writes: > On Tuesday 13 November 2012 16:23:06 SAITOU Toshihide wrote: >> In message: <201211131452.16508.hselasky@c2i.net> >> >> Hans Petter Selasky writes: >> > On Tuesday 13 November 2012 14:26:52 SAITOU Toshihide wrote: >> >> In message: <201211121342.47141.hselasky@c2i.net> >> >> >> >> Hans Petter Selasky 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