USB isoc xfers

[Maksim Yevmenkin]

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