Date: Sat, 6 May 2006 21:01:58 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: USB isoc xfers Message-ID: <1146945718.380438.1055.nullmailer@galant.ukfsn.org> In-Reply-To: <4445206D.4030109@savvis.net> References: <4423D096.2010205@udc.es> <44248823.3040907@savvis.net> <1145275616.851775.858.nullmailer@galant.ukfsn.org> <4445206D.4030109@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Apr 2006, Maksim Yevmenkin wrote: > 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! 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. 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. 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. iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1146945718.380438.1055.nullmailer>