Date: Tue, 18 Apr 2006 10:22:53 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Iain Hibbert <plunky@rya-online.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: USB isoc xfers Message-ID: <4445206D.4030109@savvis.net> In-Reply-To: <1145275616.851775.858.nullmailer@galant.ukfsn.org> References: <4423D096.2010205@udc.es> <44248823.3040907@savvis.net> <1145275616.851775.858.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain, > I am having a little trouble with the USB isoc data, and I see > you also had the same trouble.. ok > | 3) Understand and fix isoc. USB transfers (SCO data) > | > | Currenty device reports that is got zero bytes and calls > | isoc_in_complete callback over and over again. Why? > | Also might need to setup at least two isoc. transfers in > | both directions and switch them on the fly. Just to ensure > | there at least one transfer at any time ready to run. > > if you solved this already, any tips? well, i'd like to think so :) please take a look at http://mumu.org/~myevmenk/bluetooth/ng_ubt.c http://mumu.org/~myevmenk/bluetooth/ng_ubt_var.h 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. > So far I am supposing that for USB isoc transfers, the transfer would be > fulfilled in any case after a timeout (3ms ?) which is why I get zero > bytes, and I would be happy with that but it seems that the uhci/usbdi > part gets lost in a loop when I restart the xfer (possibly caused by some > DIAGNOSTIC logic) the way i understand it, isoc transfers have reserved bandwidth. it does not matter if there are data or not, the bandwidth is reserved anyway. the trick is (imo) to have enough pending isoc transfers to make sure time constrains are met. > To have isoc xfers consuming processor cycles continuously when no data is > being sent does not seem like a great idea though, maybe I got the wrong > impression there.. i do not think we do have a choice here. since the bandwidth is reserved, there has to be a transfer pending, otherwise time constrains are not met. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4445206D.4030109>