[Bluez-devel] SCO MTU problem on CSR-based Belkin F8T020/F8T007

[Bluez-devel] SCO MTU problem on CSR-based Belkin F8T020/F8T007

[Rich Townsend]

Dear all,

I've recently acquired a Belkin F8T020/F8T007 PCMCIA bluetooth interface 
(basically, a compact flash card in an adapter sleeve), and I'm trying to get 
this linked up to a Digiwave BH-2000 headset.

Mostly, everything is functioning correctly; the interface provides a UART on 
/dev/ttyS3, which Bluez has no problem working with using the hci_uart driver. 
The problem, however, comes in getting the ALSA module, snd_bt_sco, to behave 
properly. I can get the headset to connect to my computer, and do things such as 
change the volume; but I've had no luck in getting any sound to play on the headset.

After a little digging around, it turns out that no SCO packets are being 
transmitted by the interface. Closer investigation shows that the problem is 
with the outgoing MTU; the len value passed to sco_send_frame is invariably 
longer than the default SCO MTU of the interface (64), with the result that 
sco_send_frame aborts early with an EINVAL return value (which in turn is 
silently ignored).

As a test fix, I upped the SCO MTU on the interface to 255, and now stuff 
actually gets transmitted -- and I can hear sound on the headset, albeit very 
distorted.

So, it seems snd_bt_sco is disregarding the MTU settings of the interface. Why, 
I'm not sure; a quick look through the snd_bt_sco source code doesn't reveal 
anything obvious (in fact, it's not clear how the module picks up the MTU). I'd 
appreciate hearing suggestions about how I might go about fixing this.

For the record:

Kernel 2.6.16 (x86)

hciconfig -a (after upping MTU so TX works):

hci0:   Type: UART
         BD Address: 00:02:72:81:23:27 ACL MTU: 192:8 SCO MTU: 255:8
         UP RUNNING PSCAN ISCAN AUTH ENCRYPT
         RX bytes:5063515 acl:52 sco:30471 events:94 errors:0
         TX bytes:4612824 acl:42 sco:0 commands:27604 errors:0
         Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
         Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
         Link policy: RSWITCH HOLD SNIFF PARK
         Link mode: SLAVE ACCEPT
         Name: 'BlueZ (0)'
         Class: 0x000100
         Service Classes: Unspecified
         Device Class: Computer, Uncategorized
         HCI Ver: 1.1 (0x1) HCI Rev: 0x110 LMP Ver: 1.1 (0x1) LMP Subver: 0x110
         Manufacturer: Cambridge Silicon Radio (10)

hcitool info 00:13:8A:06:31:0E (the headset):

Requesting information ...
         BD Address:  00:13:8A:06:31:0E
         Device Name: BH2000
         LMP Version: 1.2 (0x2) LMP Subversion: 0x611
         Manufacturer: Cambridge Silicon Radio (10)
         Features: 0xfc 0xfe 0x0f 0x00 0x08 0x08 0x00 0x00
                 <encryption> <slot offset> <timing accuracy> <role switch>
                 <hold mode> <sniff mode> <RSSI> <channel quality> <SCO link>
                 <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
                 <paging scheme> <power control> <transparent SCO>
                 <AFH cap. slave> <AFH cap. master>

Big note: both devices are CSR, so this *ISN'T* the well-known MTU problem 
experienced by Broadcom chipsets. Smaller note: although the hciconfig output is 
after I upped the MTU and got (distorted) sound on the headset, the SCO TX count 
is still at zero. Hmmmm....

Let me know if you need more info...

cheers,

Rich





-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SCO MTU problem on CSR-based Belkin F8T020/F8T007

[Marcel Holtmann]

Hi Rich,

> I've recently acquired a Belkin F8T020/F8T007 PCMCIA bluetooth interface 
> (basically, a compact flash card in an adapter sleeve), and I'm trying to get 
> this linked up to a Digiwave BH-2000 headset.
> 
> Mostly, everything is functioning correctly; the interface provides a UART on 
> /dev/ttyS3, which Bluez has no problem working with using the hci_uart driver. 
> The problem, however, comes in getting the ALSA module, snd_bt_sco, to behave 
> properly. I can get the headset to connect to my computer, and do things such as 
> change the volume; but I've had no luck in getting any sound to play on the headset.
> 
> After a little digging around, it turns out that no SCO packets are being 
> transmitted by the interface. Closer investigation shows that the problem is 
> with the outgoing MTU; the len value passed to sco_send_frame is invariably 
> longer than the default SCO MTU of the interface (64), with the result that 
> sco_send_frame aborts early with an EINVAL return value (which in turn is 
> silently ignored).
> 
> As a test fix, I upped the SCO MTU on the interface to 255, and now stuff 
> actually gets transmitted -- and I can hear sound on the headset, albeit very 
> distorted.
> 
> So, it seems snd_bt_sco is disregarding the MTU settings of the interface. Why, 
> I'm not sure; a quick look through the snd_bt_sco source code doesn't reveal 
> anything obvious (in fact, it's not clear how the module picks up the MTU). I'd 
> appreciate hearing suggestions about how I might go about fixing this.
> 
> For the record:
> 
> Kernel 2.6.16 (x86)
> 
> hciconfig -a (after upping MTU so TX works):
> 
> hci0:   Type: UART
>          BD Address: 00:02:72:81:23:27 ACL MTU: 192:8 SCO MTU: 255:8
>          UP RUNNING PSCAN ISCAN AUTH ENCRYPT
>          RX bytes:5063515 acl:52 sco:30471 events:94 errors:0
>          TX bytes:4612824 acl:42 sco:0 commands:27604 errors:0
>          Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
>          Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
>          Link policy: RSWITCH HOLD SNIFF PARK
>          Link mode: SLAVE ACCEPT
>          Name: 'BlueZ (0)'
>          Class: 0x000100
>          Service Classes: Unspecified
>          Device Class: Computer, Uncategorized
>          HCI Ver: 1.1 (0x1) HCI Rev: 0x110 LMP Ver: 1.1 (0x1) LMP Subver: 0x110
>          Manufacturer: Cambridge Silicon Radio (10)
> 
> hcitool info 00:13:8A:06:31:0E (the headset):
> 
> Requesting information ...
>          BD Address:  00:13:8A:06:31:0E
>          Device Name: BH2000
>          LMP Version: 1.2 (0x2) LMP Subversion: 0x611
>          Manufacturer: Cambridge Silicon Radio (10)
>          Features: 0xfc 0xfe 0x0f 0x00 0x08 0x08 0x00 0x00
>                  <encryption> <slot offset> <timing accuracy> <role switch>
>                  <hold mode> <sniff mode> <RSSI> <channel quality> <SCO link>
>                  <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
>                  <paging scheme> <power control> <transparent SCO>
>                  <AFH cap. slave> <AFH cap. master>
> 
> Big note: both devices are CSR, so this *ISN'T* the well-known MTU problem 
> experienced by Broadcom chipsets. Smaller note: although the hciconfig output is 
> after I upped the MTU and got (distorted) sound on the headset, the SCO TX count 
> is still at zero. Hmmmm....
> 
> Let me know if you need more info...

run "hciconfig hci0 revision" as root and see if the SCO mapping is done
over PCM or HCI.

Regards

Marcel




_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SCO MTU problem on CSR-based Belkin F8T020/F8T007

[Rich Townsend]

Marcel Holtmann wrote:
> Hi Rich,
> 
> 
>>I've recently acquired a Belkin F8T020/F8T007 PCMCIA bluetooth interface 
>>(basically, a compact flash card in an adapter sleeve), and I'm trying to get 
>>this linked up to a Digiwave BH-2000 headset.
>>
>>Mostly, everything is functioning correctly; the interface provides a UART on 
>>/dev/ttyS3, which Bluez has no problem working with using the hci_uart driver. 
>>The problem, however, comes in getting the ALSA module, snd_bt_sco, to behave 
>>properly. I can get the headset to connect to my computer, and do things such as 
>>change the volume; but I've had no luck in getting any sound to play on the headset.
>>
>>After a little digging around, it turns out that no SCO packets are being 
>>transmitted by the interface. Closer investigation shows that the problem is 
>>with the outgoing MTU; the len value passed to sco_send_frame is invariably 
>>longer than the default SCO MTU of the interface (64), with the result that 
>>sco_send_frame aborts early with an EINVAL return value (which in turn is 
>>silently ignored).
>>
>>As a test fix, I upped the SCO MTU on the interface to 255, and now stuff 
>>actually gets transmitted -- and I can hear sound on the headset, albeit very 
>>distorted.
>>
>>So, it seems snd_bt_sco is disregarding the MTU settings of the interface. Why, 
>>I'm not sure; a quick look through the snd_bt_sco source code doesn't reveal 
>>anything obvious (in fact, it's not clear how the module picks up the MTU). I'd 
>>appreciate hearing suggestions about how I might go about fixing this.
>>
>>For the record:
>>
>>Kernel 2.6.16 (x86)
>>
>>hciconfig -a (after upping MTU so TX works):
>>
>>hci0:   Type: UART
>>         BD Address: 00:02:72:81:23:27 ACL MTU: 192:8 SCO MTU: 255:8
>>         UP RUNNING PSCAN ISCAN AUTH ENCRYPT
>>         RX bytes:5063515 acl:52 sco:30471 events:94 errors:0
>>         TX bytes:4612824 acl:42 sco:0 commands:27604 errors:0
>>         Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
>>         Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
>>         Link policy: RSWITCH HOLD SNIFF PARK
>>         Link mode: SLAVE ACCEPT
>>         Name: 'BlueZ (0)'
>>         Class: 0x000100
>>         Service Classes: Unspecified
>>         Device Class: Computer, Uncategorized
>>         HCI Ver: 1.1 (0x1) HCI Rev: 0x110 LMP Ver: 1.1 (0x1) LMP Subver: 0x110
>>         Manufacturer: Cambridge Silicon Radio (10)
>>
>>hcitool info 00:13:8A:06:31:0E (the headset):
>>
>>Requesting information ...
>>         BD Address:  00:13:8A:06:31:0E
>>         Device Name: BH2000
>>         LMP Version: 1.2 (0x2) LMP Subversion: 0x611
>>         Manufacturer: Cambridge Silicon Radio (10)
>>         Features: 0xfc 0xfe 0x0f 0x00 0x08 0x08 0x00 0x00
>>                 <encryption> <slot offset> <timing accuracy> <role switch>
>>                 <hold mode> <sniff mode> <RSSI> <channel quality> <SCO link>
>>                 <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
>>                 <paging scheme> <power control> <transparent SCO>
>>                 <AFH cap. slave> <AFH cap. master>
>>
>>Big note: both devices are CSR, so this *ISN'T* the well-known MTU problem 
>>experienced by Broadcom chipsets. Smaller note: although the hciconfig output is 
>>after I upped the MTU and got (distorted) sound on the headset, the SCO TX count 
>>is still at zero. Hmmmm....
>>
>>Let me know if you need more info...
> 
> 
> run "hciconfig hci0 revision" as root and see if the SCO mapping is done
> over PCM or HCI.

OK, here's what I get:

hci0:   Type: UART
         BD Address: 00:02:72:81:23:27 ACL MTU: 192:8 SCO MTU: 64:8
         HCI 14.3
         Chip version: BlueCore02-External (ES2)
         Max key size: 56 bit
         SCO mapping:  HCI

As you can see, the mapping is over HCI, so it should work, right?

cheers,

Rich


_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel