On Sun, 10 Dec 2006, Juan RP wrote:

> On Sunday 10 December 2006 18:14, Iain Hibbert wrote:
> > On Sun, 10 Dec 2006, Juan RP wrote:
> > > On Sunday 10 December 2006 16:38, Juan RP wrote:
> > > > accept_sco: blocksize=0 info.blocksize=800 mtu=0
> > >
> > > The problem is mtu that is 0, blocksize is fine.
> >
> > Hm, in that case I should add a check there to at least fail gracefully..
>
> Ah, so the problem was that I was using hw.ubt0.config=0!
>
> > > Anyway hardcoding the mtu value (127) does not seem to work
> > > and I can hear only distortions.
> >
> > How did you hardcode that value? 127 is likely too large - did you read
> > the CAVEAT section from ubt(4) and enable the USB isochronous data for
> > ubt?  That should explain somewhat how to calculate a proper value (its
> > suboptimal that we should have to do that, but I haven't worked out the
> > real problem in the USB stack as yet)
>
> I thought mtu was referring to net.bluetooth.rfcomm.mtu_default.

Ah, personally I think the Bluetooth spec got out of control and too many
protocols were defined. bthfp uses SCO and RFCOMM connections..

> > The MTU retrieved from the socket will be the "sco_mtu" value as reported
> > by btconfig - if this is still zero, then that is what the device is
> > reporting and I'm not sure if setting it to a higher value will work
> > properly. I understand that some older Belkin USB dongles (Broadcom 2035)
> > had trouble with SCO data and report the value in this way.
>
> I understand... I changed hw.ubt0.config to 1 and I got:
>
> [juan@nocturno][~]> sysctl -a|grep -E '(ubt|bluetooth)'
> hw.ubt0.config = 1
> hw.ubt0.alt_config = 6
> hw.ubt0.sco_rxsize = 9
> hw.ubt0.sco_txsize = 9
> [juan@nocturno][~]>
>
> But can you explain with details how to calculate the SCO packet size?

I tried to make it clear in the CAVEAT section of ubt(4) (I guess that
bthfp(1) manpage should also have a pointer to that)

The Audio data is sent over the Bluetooth link in a SCO packet, and the
device itself provides a SCO maximum payload size that it can accept. This
value will be given by the 'btconfig -v ubt0' command (sco_mtu).

SCO packets (header + payload) are chopped up into frames (of sco_txsize,
above) when they are sent via isochronous transfer over the USB bus, and I
found that if you try to send a partial frame, the USB Device/Hub will
crash. So, we need to make it so that a SCO packet fits exactly into an
integer number of frames.

Now, there are several possible configurations for the isochronous data
transfer and since they reserve bandwidth I left it turned off by default
for now.

So, since you want to use a single 16-bit voice channel (thats all thats
going to work, for now) use config#2. On my system (probably yours too,
I'm not sure) that gives me:

hw.ubt0.config = 2
hw.ubt0.alt_config = 6
hw.ubt0.sco_rxsize = 17
hw.ubt0.sco_txsize = 17

and I know the USB frame size is 17 bytes. If I enable my device, I see
that its maximum payload size is 64 bytes (yours could be something else),
and if I calculate the possible payloads that would fit exactly into
numbers of frames, I get the following:

           (17 * 1) - 3 = 14
           (17 * 2) - 3 = 31
           (17 * 3) - 3 = 48
           (17 * 4) - 3 = 65
           (17 * 5) - 3 = 82
           etc.

which means that the largest payload I can currently use is 48 so I change
the value:

% sudo btconfig ubt0 scotu 48

and now it just works with no errors..

iain

If you have suggestions to improve the CAVEAT section let me know..
(its difficult for me, because I know how it works already :)