From owner-freebsd-bluetooth@FreeBSD.ORG Mon May 8 18:03:25 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA2D916A400 for ; Mon, 8 May 2006 18:03:24 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73E8643D45 for ; Mon, 8 May 2006 18:03:24 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 095A93BE38; Mon, 8 May 2006 13:03:24 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29020-01-10; Mon, 8 May 2006 13:03:23 -0500 (CDT) Received: from [10.254.186.111] (sntc04ep01.savvis.net [64.14.1.106]) by mailgate1b.savvis.net (Postfix) with ESMTP id 88A5E3BE26; Mon, 8 May 2006 13:03:23 -0500 (CDT) Message-ID: <445F87EA.7090609@savvis.net> Date: Mon, 08 May 2006 11:03:22 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iain Hibbert References: <4423D096.2010205@udc.es> <44248823.3040907@savvis.net> <1145275616.851775.858.nullmailer@galant.ukfsn.org> <4445206D.4030109@savvis.net> <1146945718.380438.1055.nullmailer@galant.ukfsn.org> In-Reply-To: <1146945718.380438.1055.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-bluetooth@freebsd.org Subject: Re: USB isoc xfers X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2006 18:03:25 -0000 Iain, sorry for the delay. i'm completely swamped at the moment. >>this is a work in progress code that i used to receive sco data from the >>headset. this is NOT complete, its for the reference purposes. i have not >>tried to send sco data. > > Hi Max, did you do any further work on this? I have been stuck for a week > but I think I found now what has been causing me trouble, which was that > sending data proceeds for a bit, then the dongle locks up. Any bulk > transfers bomb out with IOERROR and the control pipe only returns STALLED > (trying to clear the stall does nothing). Even the flashing light goes > out! sounds bad > This seems to be caused by sending partial frames. Everything proceeds > well if I arrange the SCO packets to fill the frames exactly. eg using > config #2 (one 16-bit voice channel), with 17 byte frame lengths and 48 > (+3 hdr) byte packets then what I have works fine with 3 frames per > packet. what sco packets are you using hv1, hv2 or hv3? also i do not think it is good idea to send partial frames. sco was designed to carry 8 khz encoded (8-bit a/u-law or 13/16-bit linear) 64 kbit/sec audio stream. since over the air encoding is usually cvsd the hardware has to convert host encoding to over-the-air encoding and vice versa. > It would seem a little clunky to me to work out optimum SCO packet lengths > unless I went with one packet per frame, but the overhead could become > significant in that case. sco packet size is pretty much defined by the packet type, imo, i.e. hv1, hv2 or hv3. i'm not very clear on relation between usb packet size and sco packet size. i'm not sure if usb interface configuration needs to be switched to match sco packet selected. from my point of view hv3 packets are the best, because they consume the least amount of available slots/"bandwidth" on bluetooth link, i.e. hv3 has 30 bytes of payload, 30 bytes / 64 kbit/sec = 3.72 msec of audio. one slot is 0.625 msec, so 3.72 msec / 0.625 msec = 6. this means that to maintain half duplex 8 khz encoded 64 kbit/sec audio link with one hv3 packet has to be sent every 6th slot. to maintain full duplex link - one hv3 packet has to be sent every 3rd slot. that leaves 2 extra slots to send other acl or sco data. > I'm not sure exactly why this has been causing trouble, because the usb > hardware/driver does feel free to provide partial incoming frames > sometimes. I glanced at the uhci spec and see nothing obviously forbidding > it there, and the uhci driver similarly. It would be interesting to see if > FreeBSD gives the same results, since the usb drivers are the same. perhaps you need to allow "short transfers"? thanks, max