USB isoc xfers

[Iain Hibbert]

On Mon, 8 May 2006, Maksim Yevmenkin wrote:

> what sco packets are you using hv1, hv2 or hv3?

I allow any or all types, I can't really think of a good reason to tweak
that and I'm sure it says somewhere in the HCI docs that enabling
everything is probably better unless you have a good reason.

> 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.

I havent tried different voice settings than the default as yet

> sco packet size is pretty much defined by the packet type, imo, i.e.
> hv1, hv2 or hv3.

Well, I'm thinking the 'on air' packet type is mostly irrelevant here
because the controller is taking the data and encoding it differently, and
the SCO packets only exist between the Host and Controller. So, if I send
24 words of linear I'm not sure how that translates to cvsd anyway, but
sure the dongle must be doing some per channel buffering.

> 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.

Yeah, I think it might be - I have dodged around that issue by providing a
sysctl knob "hw.ubt0.config" to select the configuration and leave it up
to the sysadmin to set what they need, but so far I can only support one
voice channel properly anyway because I need to think about a fair queuing
mechanism, so I think config #2 is probably the best.  Actually, I'm
fairly unclear on the usb isoc transfers - it seems to say in the book
that each frame takes 1ms, so I think if I set config #5 with 49 byte
frames, there will be overruns.

In any case, using config #2 (17 byte frames) and 48 byte SCO packets (==3
frames exactly) seems to work ok for 3 minutes of audio.

(I should sample a longer track maybe, I am getting bored with that one :)

> perhaps you need to allow "short transfers"?

Well, I'm willing to try anything - lack of documentation is great :)

I think most of the problems I am seeing are really problems in the isoc
part of the USB stack, which is not well used. I emailed this Hans Petter
Selasky guy from FreeBSD that is rewriting the USB stack and he says the
current one does have some problems with isoc, but I didnt try his version
as yet.

iain