USB isoc xfers

Hi Maksim,
          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?

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)

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

regards,
iain
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

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://m
umu.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
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On Tue, 18 Apr 2006, Maksim Yevmenkin wrote:

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

Ahh, thanks - I see that you are using multiple transfers..
I wonder if
that will help with the problems I was seeing today. As you
can see in the
attached dump I inserted a line break in between observed
packets (handle
0x002d, length 0x30, framesize 9 bytes) but it is clearly
nonsense and
there is no way for my code to find where packets start and
finish. I
memset the buffer with 0xaa before the transfer and data is
missing in
places and present in other places but the frame is marked
empty.

In fact most of the problems I see are at the start/end of
transfers
though, so that may be the exact fix.

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

I found this locking up problem in the uhci code and
actually I'm not sure
that you will have come across it (I think the usb code is
common) since
your callback routine does not recycle the transfer right
away but rather
switches context (?) with the ng_send_fn() call before
restarting. I was
doing as (the NetBSD) ugen does and just recycle the xfer
directly from
the callback, but something further down was trying to
reference the
previous state.

This also might be causing my problems at the start/end of
xfers.

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

In order to offset this (and also as I was trying to work
out what was
going on), I made a sysctl variable to control which
alternate
configuration is used - it can only be set before the
controller is
enabled and will default to the zero setting so that cycles
are not wasted
if the user does not want to use isoc data.

I might take that out though, since it does not seem to
impact the system
especially to have transfers completing empty. I roughly
noted 2000 in 10
minutes which I think is every ~30ms and hm, thinking about
it that would
be about right because each frame is, I think, 1ms, and I
was using the
lowest configuration. At 9 bytes per frame, there were 28
frames in the
buffer which I made big enough to handle a maximum SCO
packet (0xff + 3).

Ahh, and now I have the idea that it may be better to
calculate the isoc
buffer size so that a fixed number of frames fit into each
buffer, rather
than calculating the number of frames that will fit into a
fixed buffer..
that way, the number of transfers would remain constant over
differing
loads as each would be time stable.

regards,
iainApr 18 18:20:23 galant bthcid[399]: Sending
Link_Key_Reply to ubt0 for remote bdaddr 00:07:a4:23:10:83
Apr 18 18:20:24 galant /netbsd: ubt_recv_sco_complete:
sc=0xc0a07a00, count=33
Apr 18 18:20:24 galant /netbsd: frame  0 (size  0): a4 01 39
01 bc 00 c9 00 6e
Apr 18 18:20:24 galant /netbsd: frame  1 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  2 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  3 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  4 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  5 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  6 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  7 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  8 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  9 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 10 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 11 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 12 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 13 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 14 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 15 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 16 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 17 (size  0): ff ff ec
ff 19 ff 61 fc e6
Apr 18 18:20:24 galant /netbsd: frame 18 (size  0): f7 a3 f4
bf f2 11 ed cf ec
Apr 18 18:20:24 galant /netbsd: frame 19 (size  0): 93 ed 83
eb 06 f4 aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 20 (size  0): 2d 00 30
bc ee 7b f2 1a fd
Apr 18 18:20:24 galant /netbsd: frame 21 (size  0): c1 f6 f9
fa 0b fe dd f7 84
Apr 18 18:20:24 galant /netbsd: frame 22 (size  0): 00 c9 fa
96 fe 7f ff ca fb
Apr 18 18:20:24 galant /netbsd: frame 23 (size  0): b2 00 62
fd d0 ff 7b ff bc
Apr 18 18:20:24 galant /netbsd: frame 24 (size  0): fe 98 00
76 01 c2 00 fa 00
Apr 18 18:20:24 galant /netbsd: frame 25 (size  6): 68 00 91
00 53 00 aa aa aa

Apr 18 18:20:24 galant /netbsd: frame 26 (size  9): 2d 00 30
4f 00 4e 01 d8 01
Apr 18 18:20:24 galant /netbsd: frame 27 (size  9): 42 01 d8
00 d1 00 1e 01 d6
Apr 18 18:20:24 galant /netbsd: frame 28 (size  9): 00 b8 00
7c 00 6f 00 dd 00
Apr 18 18:20:24 galant /netbsd: ptr=0xc08c095a,
buf=0xcaa8e105, m_len=34, count=33, m_pkthdr.len=34
Apr 18 18:20:24 galant /netbsd: ubt_recv_sco_complete:
sc=0xc0a07a00, count=135
Apr 18 18:20:24 galant /netbsd: frame  0 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  1 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  2 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  3 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  4 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  5 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  6 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  7 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  8 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  9 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 10 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 11 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 12 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame 13 (size  9): 00 75 00
71 00 17 01 8e 01
Apr 18 18:20:24 galant /netbsd: frame 14 (size  6): 12 00 88
00 23 01 aa aa aa

Apr 18 18:20:24 galant /netbsd: frame 15 (size  9): 2d 00 30
fb 00 8c 00 90 00
Apr 18 18:20:24 galant /netbsd: frame 16 (size  9): 5c 00 4d
00 41 00 44 00 fb
Apr 18 18:20:24 galant /netbsd: frame 17 (size  9): ff 4d ff
86 ff a7 ff 46 ff
Apr 18 18:20:24 galant /netbsd: frame 18 (size  9): 4e 00 4a
00 28 00 02 00 00
Apr 18 18:20:24 galant /netbsd: frame 19 (size  9): 00 ff ff
00 00 fd ff 00 00
Apr 18 18:20:24 galant /netbsd: frame 20 (size  6): fe ff ff
ff ff ff aa aa aa

Apr 18 18:20:24 galant /netbsd: frame 21 (size  9): 2d 00 30
fe ff ff ff fe ff
Apr 18 18:20:24 galant /netbsd: frame 22 (size  9): ff ff fe
ff fe ff fe ff fe
Apr 18 18:20:24 galant /netbsd: frame 23 (size  9): ff ff ff
fe ff fe ff ff ff
Apr 18 18:20:24 galant /netbsd: frame 24 (size  9): fe ff fe
ff ff ff fe ff ff
Apr 18 18:20:24 galant /netbsd: frame 25 (size  9): ff fe ff
d8 ff ce ff c4 ff
Apr 18 18:20:24 galant /netbsd: frame 26 (size  6): 65 ff 6d
ff b5 ff aa aa aa

Apr 18 18:20:24 galant /netbsd: frame 27 (size  9): 2d 00 30
a8 ff c0 ff 75 ff
Apr 18 18:20:24 galant /netbsd: frame 28 (size  9): 50 ff a0
ff a2 ff bf ff 99
Apr 18 18:20:24 galant /netbsd: ptr=0xc08c09c0,
buf=0xcaa8e105, m_len=136, count=135, m_pkthdr.len=136
Apr 18 18:20:24 galant /netbsd: ubt_recv_sco_complete:
sc=0xc0a07a00, count=237
Apr 18 18:20:24 galant /netbsd: frame  0 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  1 (size  9): 57 ff 9c
ff 76 ff 54 ff 6f
Apr 18 18:20:24 galant /netbsd: frame  2 (size  9): ff 94 ff
5b ff 57 ff 85 ff
Apr 18 18:20:24 galant /netbsd: frame  3 (size  6): 49 ff 56
ff 5d ff aa aa aa

Apr 18 18:20:24 galant /netbsd: frame  4 (size  9): 2d 00 30
27 ff 3d ff 39 ff
Apr 18 18:20:24 galant /netbsd: frame  5 (size  9): 2c ff 34
ff 1c ff 33 ff 54
Apr 18 18:20:24 galant /netbsd: frame  6 (size  9): ff 3e ff
21 ff 25 ff 23 ff
Apr 18 18:20:24 galant /netbsd: frame  7 (size  9): 1e ff 17
ff 0a ff 05 ff 11
Apr 18 18:20:24 galant /netbsd: frame  8 (size  9): ff f7 fe
05 ff 1b ff 0d ff
Apr 18 18:20:24 galant /netbsd: frame  9 (size  6): eb fe 03
ff 0e ff aa aa aa

Apr 18 18:20:24 galant /netbsd: frame 10 (size  9): 2d 00 30
ef fe 0b ff 02 ff
Apr 18 18:20:24 galant /netbsd: frame 11 (size  9): e1 fe f8
fe f0 fe f9 fe ed
Apr 18 18:20:24 galant /netbsd: frame 12 (size  9): fe eb fe
10 ff f2 fe c6 fe
Apr 18 18:20:24 galant /netbsd: frame 13 (size  9): ea fe ec
fe dd fe ee fe da
Apr 18 18:20:24 galant /netbsd: frame 14 (size  9): fe d7 fe
eb fe fa fe e5 fe
Apr 18 18:20:24 galant /netbsd: frame 15 (size  6): d9 fe e9
fe f7 fe aa aa aa

Apr 18 18:20:24 galant /netbsd: frame 16 (size  9): 2d 00 30
c9 fe c4 fe ed fe
Apr 18 18:20:24 galant /netbsd: frame 17 (size  9): be fe a2
fe a7 fe b1 fe b8
Apr 18 18:20:24 galant /netbsd: frame 18 (size  9): fe cd fe
d4 fe cd fe c6 fe
Apr 18 18:20:24 galant /netbsd: frame 19 (size  9): d1 fe c3
fe cb fe b4 fe c3
Apr 18 18:20:24 galant /netbsd: frame 20 (size  9): fe cf fe
c4 fe de fe c6 fe
Apr 18 18:20:24 galant /netbsd: frame 21 (size  6): a6 fe bf
fe b1 fe aa aa aa

Apr 18 18:20:24 galant /netbsd: frame 22 (size  9): 2d 00 30
af fe d3 fe c9 fe
Apr 18 18:20:24 galant /netbsd: frame 23 (size  9): b5 fe bd
fe ca fe be fe cd
Apr 18 18:20:24 galant /netbsd: frame 24 (size  9): fe b7 fe
b4 fe cb fe ac fe
Apr 18 18:20:24 galant /netbsd: frame 25 (size  9): b1 fe ae
fe 92 fe c0 fe cb
Apr 18 18:20:24 galant /netbsd: frame 26 (size  9): fe ae fe
c5 fe bf fe af fe
Apr 18 18:20:24 galant /netbsd: frame 27 (size  6): bf fe ac
fe ac fe aa aa aa

Apr 18 18:20:24 galant /netbsd: frame 28 (size  9): 2d 00 30
aa fe 96 fe c0 fe
Apr 18 18:20:24 galant /netbsd: ptr=0xc08c0c4a,
buf=0xcaa8e105, m_len=42, count=237, m_pkthdr.len=238
Apr 18 18:20:24 galant /netbsd: ubt_recv_sco_complete:
sc=0xc0a07a00, count=237
Apr 18 18:20:24 galant /netbsd: frame  0 (size  0): aa aa aa
aa aa aa aa aa aa
Apr 18 18:20:24 galant /netbsd: frame  1 (size  9): fe b7 fe
be fe 9b fe b8 fe
Apr 18 18:20:24 galant /netbsd: frame  2 (size  9): 97 fe b9
fe b2 fe a9 fe aa
Apr 18 18:20:24 galant /netbsd: frame  3 (size  9): fe 8c fe
bd fe c0 fe a7 fe
Apr 18 18:20:24 galant /netbsd: frame  4 (size  6): af fe ac
fe af fe aa aa aa
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On Tue, 18 Apr 2006, Maksim Yevmenkin wrote:

> i have not tried to send sco data.

I am trying this now and got more trouble 

I can't get the devices I have here (a csr v2.0 and a
belkin v1.2) to send
NUM_COMPLETE_PACKETS for SCO handles.. the csr returns 0x11
"unsupported
feature" for WRITE_SCO_FLOW_CONTROL even though the
READ_LOCAL_COMMANDS
says it can do that command (well, turning it off seems to
work ,
and
the belkin says ok but READ_BUFFER_SIZE always returns 0 for
num_sco_packets. Did you find any of this yet?

I think it will have to be done differently..

I looked at Affix and from what I can understand they seem
to have a timer
that keeps the queue topped up. I couldnt work out what
BlueZ does
exactly, and I'm trying to think if there is a better way..
 seems that
the device could send some notification when it took packets
off the
outputq which would trigger more to be queued, or even just
send the
packets back via a different method (so empty packet is
message), hm..

regards,
iain
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On Tue, 18 Apr 2006, Maksim Yevmenkin wrote:

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

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.

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.

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.

iain
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

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
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

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
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"