From owner-freebsd-usb@FreeBSD.ORG Tue Nov 13 13:27:02 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 188F97A2 for ; Tue, 13 Nov 2012 13:27:02 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from msgw002-02.ocn.ad.jp (msgw002-02.ocn.ad.jp [180.37.203.77]) by mx1.freebsd.org (Postfix) with ESMTP id B49E58FC13 for ; Tue, 13 Nov 2012 13:27:01 +0000 (UTC) Received: from localhost (p15134-ipngn100102sizuokaden.shizuoka.ocn.ne.jp [180.51.198.134]) by msgw002-02.ocn.ad.jp (Postfix) with ESMTP id A36EA1F7092; Tue, 13 Nov 2012 22:26:54 +0900 (JST) Date: Tue, 13 Nov 2012 22:26:52 +0900 (JST) Message-Id: <20121113.222652.71084426.toshi@ruby.ocn.ne.jp> To: hselasky@c2i.net Subject: Re: isochronous transfer packet is out of sequence From: SAITOU Toshihide In-Reply-To: <201211121342.47141.hselasky@c2i.net> References: <20121112.205208.208974549.toshi@ruby.ocn.ne.jp> <201211121342.47141.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: Tue, 13 Nov 2012 13:27:02 -0000 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. >> >> >> ----- log (1) >> 049 4437e06b 0 c 818 >> 04a 4437e06b 0 c c00 >> 04b 4437e06b 0 c 818 >> UVC_STREAM_EOF >> total a1400 >> 04c 4402516b 1 c b9c >> 04d 4402516b 1 c 87c >> 04e 4402516b 1 c 800 >> 04f 4402516b 1 c c00 >> 050 4402516b 1 c 800 >> 051 4437e06b 0 c c00 >> 052 4437e06b 0 c 744 >> 053 4437e06b 0 c c00 >> >> >> ----- callback function >> static void cb(struct libusb_transfer *xfer) >> { >> uint8_t *p; >> int plen; >> int i; >> >> p = xfer->buffer; >> >> for (i = 0; i < xfer->num_iso_packets; i++, p += PKT_LEN) >> { >> if (xfer->iso_packet_desc[i].status == >> LIBUSB_TRANSFER_COMPLETED) { >> plen = xfer->iso_packet_desc[i].actual_length; >> >> if (plen < 2) >> continue; >> >> if (p[1] & UVC_STREAM_ERR) // bmHeaderInfo >> continue; >> >> fprintf(stderr, "%03x ", i); >> fprintf(stderr, "%08x ", p[2] | p[3]<<8 | p[4]<<16 >> | p[5]<<24); // pts fprintf(stderr, "%01x ", p[1] & UVC_STREAM_FID); // >> fid fprintf(stderr, "%01x ", p[0]); // header length fprintf(stderr, >> "%x\n", plen); // actual length >> >> total += plen - p[0]; >> >> if (p[1] & UVC_STREAM_EOF) >> { >> fprintf(stderr, "UVC_STREAM_EOF\n", total); >> fprintf(stderr, "total %x\n", total); >> >> if (total < FrameSize) >> { >> fprintf(stderr, "insufficient frame data.\n"); >> write(fd, padding, FrameSize - total); // zero padding >> } >> total = 0; >> } >> write(fd, p + p[0], plen - p[0]); // write payload data >> } >> } >> >> if (libusb_submit_transfer(xfer) != 0) >> { >> fprintf(stderr, "submit transfer failed.\n"); >> } >> } > > Hi, > > You need to submit two transfers for continued operation. I may have a misunderstanding but I submit two transfers at start and it is resubmited in the callback function, then I see the packet group in the wrong place. It seems that the callback function was excuted exclusively so the iso packets in the data buffer were out of order, just like the packet does not correctly assign to the two transfers. I can get the video on the MacBook(2). I confirmed using mplayer. --- SAITOU Toshihide