USB isoc xfers
maksim.yevmenkin at savvis.net
Tue Apr 18 17:22:57 UTC 2006
> I am having a little trouble with the USB isoc data, and I see
> you also had the same trouble..
> | 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
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.
More information about the freebsd-bluetooth