Hi,
We have a strange compatible problem with Bluez for eSCO audio.
We develope an embedded application based on Bluez library that can play the
role of HF and it uses a generic CSR USB Bluetooth dongle. The application
worked well for most cell phones (iPhone, Blackberry etc). But when we tried
it with an Android phone (Motorola Droid), we found one way voice problem.
The Android phone side can not hear the voice.
We know that Android phone also uses the Bluez library. So we tried to pair
our application with another Linux with Bluez library with another CSR USB
Bluetooth dongle. We used "hcidump" to capture the SCO packets in that
system. We received a lot of SCO packets, but the content of packets is all
zero. However from another end of SCO connection, we actually sent a lot
non-zero contents.
To simply our debug, we then used the "scotest" program from the Bluez 4.65
source and used one system as client and another as server. From the hcidump
output, we still saw the content of packets is all zero. However when we
changed one USB dongle to another USB dongle with the Broadcom chipset, we
can receive some non-zero data. In both case, we didn't see Bluez kernel
error message.
The Linux kernel for the system we used for test is 2.6.30. The attachment
is the SCO packet we captured for receiving side. The following is the
information of Bluetooth USB dongle we use:
hciconfig -a
hci0: Type: USB
BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN AUTH ENCRYPT
RX bytes:2081370 acl:185 sco:17775 events:9695 errors:0
TX bytes:252089 acl:164 sco:3002 commands:4693 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'test'
Class: 0x000408
Service Classes: Unspecified
Device Class: Audio/Video, Hands-free
HCI Ver: 2.0 (0x3) HCI Rev: 0xc5c LMP Ver: 2.0 (0x3) LMP Subver:
0xc5c
Manufacturer: Cambridge Silicon Radio (10)
hciconfig hci0 revision:
hci0: Type: USB
BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
Unified 21e
Chip version: BlueCore4-ROM
Max key size: 128 bit
SCO mapping: HCI
This audio problem seems only happen if both ends use Bluez library. If one
side uses a different Bluetooth library, this issue will not appear. What
can be the cause of this? I am very confused.
Hi Marcel,
Do you have any clue what happened? I tried the same test with the latest
Linux 2.6.34-rc2 kernel and had the same result. This seemed to be easily
reproducible with two CSR USB dongles of LMP Subver 0xc5c.
Thanks
Cooper
-----Original Message-----
From: Marcel Holtmann [mailto:[email protected]]
Sent: Monday, March 15, 2010 10:38 PM
To: Cooper Xu
Cc: [email protected]
Subject: RE: A strange compatible problem for eSCO audio with CSR USB
Bluetooth dongle
Hi Cooper,
no top posting on this mailing list. We do proper inline quoting.
> I used the attached scotest.c to do the test for both client and server.
> This file is from Bluez 4.58. I modified a little because the original is
> sending packets too fast. I turned off eSCO according to Nick's
suggestion.
the scotest.c tool is just for basic testing. There is no guarantee that
it does the right job. Some devices might send silence if the Headset or
Handsfree profile is not fully setup.
Regards
Marcel
Hi Marcel,
Another thing worth to say is that so far I found the pattern is like the
following:
If the sender side is CSR chipset USB dongle with Bluez and receiver side is
also Bluez, it will most likely read all zero.
If the sender side is CSR chipset USB dongle with Bluez and receiver side is
NOT Bluez, it seems OK.
If the sender side is another chipset and receiver side is also Bluez, it
seems OK, but voice is a little choppy.
Cooper
-----Original Message-----
From: Marcel Holtmann [mailto:[email protected]]
Sent: Monday, March 15, 2010 10:38 PM
To: Cooper Xu
Cc: [email protected]
Subject: RE: A strange compatible problem for eSCO audio with CSR USB
Bluetooth dongle
Hi Cooper,
no top posting on this mailing list. We do proper inline quoting.
> I used the attached scotest.c to do the test for both client and server.
> This file is from Bluez 4.58. I modified a little because the original is
> sending packets too fast. I turned off eSCO according to Nick's
suggestion.
the scotest.c tool is just for basic testing. There is no guarantee that
it does the right job. Some devices might send silence if the Headset or
Handsfree profile is not fully setup.
Regards
Marcel
Hi Marcel,
I had tried with device class to 0x200404 and it didn't make any difference.
I use the "scotest.c" to simplify the debug. The actual application is much
more complicated. But the issue is similar with test result of "scotest.c".
I assume the "scotest.c" should give me some valid data, as I sent so many
real data from one side. I can actually receive real data with some USB
dongles. But I have problem CSR chipset USB dongles with relatively newer
firmware. That is something real confused me.
Regards,
Cooper
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Marcel Holtmann
Sent: Monday, March 15, 2010 10:38 PM
To: Cooper Xu
Cc: [email protected]
Subject: RE: A strange compatible problem for eSCO audio with CSR USB
Bluetooth dongle
Hi Cooper,
no top posting on this mailing list. We do proper inline quoting.
> I used the attached scotest.c to do the test for both client and server.
> This file is from Bluez 4.58. I modified a little because the original is
> sending packets too fast. I turned off eSCO according to Nick's
suggestion.
the scotest.c tool is just for basic testing. There is no guarantee that
it does the right job. Some devices might send silence if the Headset or
Handsfree profile is not fully setup.
Regards
Marcel
Hi Cooper,
no top posting on this mailing list. We do proper inline quoting.
> I used the attached scotest.c to do the test for both client and server.
> This file is from Bluez 4.58. I modified a little because the original is
> sending packets too fast. I turned off eSCO according to Nick's suggestion.
the scotest.c tool is just for basic testing. There is no guarantee that
it does the right job. Some devices might send silence if the Headset or
Handsfree profile is not fully setup.
Regards
Marcel
Hi Marcel,
I used the attached scotest.c to do the test for both client and server.
This file is from Bluez 4.58. I modified a little because the original is
sending packets too fast. I turned off eSCO according to Nick's suggestion.
The sco_sender.txt and sco_recevier.txt are captured log files from the
test. The information of Bluetooth dongle is at the beginning of file. Both
machines are running Fedora 11 virtual machine with kernel 2.6.30.8.
The dongle of one machine is internal Bluetooth module of the first
generation x86 Macbook. Dongle of another machine is Cirago BTA-3190. I had
tried other brand generic USB dongles with LMP Subver "0xc5c", which I saw
in a lot of Bluetooth dongles. I got the same result. So I think this issue
should be reproducible with other CSR USB dongle.
To have this issue, Both side must to be Bluez and one or both side have to
use CSR Bluetooth dongle. I tested with Blackberry curve 8310, which is also
CSR chipset with LMP Subver "0xc5c", but doesn't have this issue. I haven't
try 2.6.34-rc1 yet, I will try it as soon as possible.
Regards,
Cooper
-----Original Message-----
From: Marcel Holtmann [mailto:[email protected]]
Sent: Sunday, March 14, 2010 7:29 PM
To: Cooper Xu
Cc: [email protected]
Subject: Re: A strange compatible problem for eSCO audio with CSR USB
Bluetooth dongle
Hi Cooper,
> We have a strange compatible problem with Bluez for eSCO audio.
>
> We develope an embedded application based on Bluez library that can play
the
> role of HF and it uses a generic CSR USB Bluetooth dongle. The application
> worked well for most cell phones (iPhone, Blackberry etc). But when we
tried
> it with an Android phone (Motorola Droid), we found one way voice problem.
> The Android phone side can not hear the voice.
do you have a link to your sources so that we can have a look at it.
> We know that Android phone also uses the Bluez library. So we tried to
pair
> our application with another Linux with Bluez library with another CSR USB
> Bluetooth dongle. We used "hcidump" to capture the SCO packets in that
> system. We received a lot of SCO packets, but the content of packets is
all
> zero. However from another end of SCO connection, we actually sent a lot
> non-zero contents.
>
> To simply our debug, we then used the "scotest" program from the Bluez
4.65
> source and used one system as client and another as server. From the
hcidump
> output, we still saw the content of packets is all zero. However when we
> changed one USB dongle to another USB dongle with the Broadcom chipset, we
> can receive some non-zero data. In both case, we didn't see Bluez kernel
> error message.
If you are using BlueZ 4.65 then I want a ride in your time machine ;)
> The Linux kernel for the system we used for test is 2.6.30. The
attachment
> is the SCO packet we captured for receiving side. The following is the
> information of Bluetooth USB dongle we use:
>
> BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
> UP RUNNING PSCAN AUTH ENCRYPT
Bluetooth security mode 3. Seriously? Who still thinks this is a good
idea. I don't get it.
> BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
> Unified 21e
> Chip version: BlueCore4-ROM
> Max key size: 128 bit
> SCO mapping: HCI
So at least the SCO mapping is correctly set to HCI.
For the 2.6.30 kernel, that is a pretty ancient kernel. It is most
likely over 9 month old. I would prefer if you can re-test it with a
2.6.34-rc1 kernel to ensure there is no kernel issue.
> This audio problem seems only happen if both ends use Bluez library. If
one
> side uses a different Bluetooth library, this issue will not appear. What
> can be the cause of this? I am very confused.
Nothing can really cause this. Please show us the source code for your
application maybe someone can have a quick look. The BlueZ builtin
headset and handsfree support works perfectly.
Regards
Marcel
Thanks, I will try it.
The strange thing is the eSCO audio worked ok with Blackberry curve 8310,
which seems to use the same CSR BlueCore4 chipset and firmware version
0xc5c. I assume the library of Blackberry is not Bluez.
But when I use a PC with CSR BlueCore4 dongle with USB interface and Bluez
library as the remote for testing, from the captured eSCO stream, I can not
see any real data I sent, I got all zero.
However If I changed the USB dongle to Broadcom chipset, I can see a few
real data from captured eSCO stream (not all of data I sent, some seemed
lost or being replaced by zero).
-----Original Message-----
From: Nick Pelly [mailto:[email protected]]
Sent: Monday, March 15, 2010 5:35 PM
To: Cooper Xu
Cc: [email protected]
Subject: Re: A strange compatible problem for eSCO audio with CSR USB
Bluetooth dongle
I wonder if this is some eSCO packet type incompatibility between
chipsets. Try setting /sys/module/sco/parameters/disable_esco to 1 to
see if this resolves the issue.
Nick
On Sun, Mar 14, 2010 at 4:01 PM, Cooper Xu <[email protected]> wrote:
> Hi,
>
>
> We have a strange compatible problem with Bluez for eSCO audio.
>
> We develope an embedded application based on Bluez library that can play the
> role of HF and it uses a generic CSR USB Bluetooth dongle. The application
> worked well for most cell phones (iPhone, Blackberry etc). But when we tried
> it with an Android phone (Motorola Droid), we found one way voice problem.
> The Android phone side can not hear the voice.
>
> We know that Android phone also uses the Bluez library. So we tried to pair
> our application with another Linux with Bluez library with another CSR USB
> Bluetooth dongle. We used "hcidump" to capture the SCO packets in that
> system. We received a lot of SCO packets, but the content of packets is all
> zero. However from another end of SCO connection, we actually sent a lot
> non-zero contents.
>
> To simply our debug, we then used the "scotest" program from the Bluez 4.65
> source and used one system as client and another as server. From the hcidump
> output, we still saw the content of packets is all zero. However when we
> changed one USB dongle to another USB dongle with the Broadcom chipset, we
> can receive some non-zero data. In both case, we didn't see Bluez kernel
> error message.
>
> The Linux kernel for the system we used for test is 2.6.30. ?The attachment
> is the SCO packet we captured for receiving side. The following is the
> information of Bluetooth USB dongle we use:
>
>
> ? ? ? ?hciconfig -a
>
> ? ? ? ?hci0: ? Type: USB
>
> ? ? ? ?BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
> ? ? ? ?UP RUNNING PSCAN AUTH ENCRYPT
> ? ? ? ?RX bytes:2081370 acl:185 sco:17775 events:9695 errors:0
> ? ? ? ?TX bytes:252089 acl:164 sco:3002 commands:4693 errors:0
> ? ? ? ?Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
> ? ? ? ?Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> ? ? ? ?Link policy: RSWITCH HOLD SNIFF PARK
> ? ? ? ?Link mode: SLAVE ACCEPT
> ? ? ? ?Name: 'test'
> ? ? ? ?Class: 0x000408
> ? ? ? ?Service Classes: Unspecified
> ? ? ? ?Device Class: Audio/Video, Hands-free
> ? ? ? ?HCI Ver: 2.0 (0x3) HCI Rev: 0xc5c LMP Ver: 2.0 (0x3) LMP Subver:
> 0xc5c
> ? ? ? ?Manufacturer: Cambridge Silicon Radio (10)
>
>
>
> ? ? ? ?hciconfig hci0 revision:
>
> ? ? ? ?hci0: ? Type: USB
>
> ? ? ? ? ?BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
> ? ? ? ? ?Unified 21e
> ? ? ? ? ?Chip version: BlueCore4-ROM
> ? ? ? ? ?Max key size: 128 bit
> ? ? ? ? ?SCO mapping: ?HCI
>
>
> This audio problem seems only happen if both ends use Bluez library. If one
> side uses a different Bluetooth library, this issue will not appear. What
> can be the cause of this? I am very confused.
I wonder if this is some eSCO packet type incompatibility between
chipsets. Try setting /sys/module/sco/parameters/disable_esco to 1 to
see if this resolves the issue.
Nick
Hi Cooper,
> We have a strange compatible problem with Bluez for eSCO audio.
>
> We develope an embedded application based on Bluez library that can play the
> role of HF and it uses a generic CSR USB Bluetooth dongle. The application
> worked well for most cell phones (iPhone, Blackberry etc). But when we tried
> it with an Android phone (Motorola Droid), we found one way voice problem.
> The Android phone side can not hear the voice.
do you have a link to your sources so that we can have a look at it.
> We know that Android phone also uses the Bluez library. So we tried to pair
> our application with another Linux with Bluez library with another CSR USB
> Bluetooth dongle. We used "hcidump" to capture the SCO packets in that
> system. We received a lot of SCO packets, but the content of packets is all
> zero. However from another end of SCO connection, we actually sent a lot
> non-zero contents.
>
> To simply our debug, we then used the "scotest" program from the Bluez 4.65
> source and used one system as client and another as server. From the hcidump
> output, we still saw the content of packets is all zero. However when we
> changed one USB dongle to another USB dongle with the Broadcom chipset, we
> can receive some non-zero data. In both case, we didn't see Bluez kernel
> error message.
If you are using BlueZ 4.65 then I want a ride in your time machine ;)
> The Linux kernel for the system we used for test is 2.6.30. The attachment
> is the SCO packet we captured for receiving side. The following is the
> information of Bluetooth USB dongle we use:
>
> BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
> UP RUNNING PSCAN AUTH ENCRYPT
Bluetooth security mode 3. Seriously? Who still thinks this is a good
idea. I don't get it.
> BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
> Unified 21e
> Chip version: BlueCore4-ROM
> Max key size: 128 bit
> SCO mapping: HCI
So at least the SCO mapping is correctly set to HCI.
For the 2.6.30 kernel, that is a pretty ancient kernel. It is most
likely over 9 month old. I would prefer if you can re-test it with a
2.6.34-rc1 kernel to ensure there is no kernel issue.
> This audio problem seems only happen if both ends use Bluez library. If one
> side uses a different Bluetooth library, this issue will not appear. What
> can be the cause of this? I am very confused.
Nothing can really cause this. Please show us the source code for your
application maybe someone can have a quick look. The BlueZ builtin
headset and handsfree support works perfectly.
Regards
Marcel
Hi,
I was written to this list one month ago about a strange compatible problem
between Bluetooth dongle of CSR chipset with HCI Rev: 0xc5c and Bluez. The
phenomena were that the eSCO connection can be made without any problem, but
I received all zero for voice data.
After some tests with several USB Dongles of CSR chipset, I found that if I
turned off eSCO, I am able to get real voice data.
The strange thing is that I used a host with Bluez and CSR dongle to test
the eSCO connection with Blackberry 8310 curve, which Blackberry has the CSR
chipset and HCI Rev: 0xc5c, the voice data worked without problem. However
if I use two hosts with CSR dongles and Bluez at the both ends, the eSCO
connection keeps receiving zero for voice data. This problem exists with all
CSR USB dongles I tried including a Bluetooth 2.1 dongle. If I turn off eSCO
mode, this problem will go away.
Does any one have clue why the eSCO connection will receive all zero if the
both side of eSCO connection are using Bluez and CSR chipset? How can eSCO
connection not compatible between USB dongles with the same CSR chipset and
firmware?
Thanks,
Cooper