* [Bluez-devel] SCO MTU problem on CSR-based Belkin F8T020/F8T007
@ 2006-05-16 2:27 Rich Townsend
2006-05-29 13:36 ` Marcel Holtmann
0 siblings, 1 reply; 3+ messages in thread
From: Rich Townsend @ 2006-05-16 2:27 UTC (permalink / raw)
To: Bluez Developers
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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [Bluez-devel] SCO MTU problem on CSR-based Belkin F8T020/F8T007
2006-05-16 2:27 [Bluez-devel] SCO MTU problem on CSR-based Belkin F8T020/F8T007 Rich Townsend
@ 2006-05-29 13:36 ` Marcel Holtmann
2006-06-02 17:38 ` Rich Townsend
0 siblings, 1 reply; 3+ messages in thread
From: Marcel Holtmann @ 2006-05-29 13:36 UTC (permalink / raw)
To: bluez-devel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bluez-devel] SCO MTU problem on CSR-based Belkin F8T020/F8T007
2006-05-29 13:36 ` Marcel Holtmann
@ 2006-06-02 17:38 ` Rich Townsend
0 siblings, 0 replies; 3+ messages in thread
From: Rich Townsend @ 2006-06-02 17:38 UTC (permalink / raw)
To: BlueZ development
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-06-02 17:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-16 2:27 [Bluez-devel] SCO MTU problem on CSR-based Belkin F8T020/F8T007 Rich Townsend
2006-05-29 13:36 ` Marcel Holtmann
2006-06-02 17:38 ` Rich Townsend
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).