USB isoc xfers

[Maksim Yevmenkin]

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