Subject: Re: comms/bthfp floating point exception
To: Juan RP <email@example.com>
From: Iain Hibbert <firstname.lastname@example.org>
Date: 12/10/2006 19:09:34
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
> 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
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
which means that the largest payload I can currently use is 48 so I change
% sudo btconfig ubt0 scotu 48
and now it just works with no errors..
If you have suggestions to improve the CAVEAT section let me know..
(its difficult for me, because I know how it works already :)