HFP/HSP Telephony profile doesn't work with Bluetooth USB dongle

Greetings,

Using Fedora 18 x86_64, I've tested two different USB Bluetooth dongles (cheap generic Cambridge Silicon and more expensive BlueRigger BTD-400) and two different headsets (Motorola SF600, BrainyTrade BH-M20), in all combinations, the A2DP High-Fidelity profile for audio output works, but the HFP/HSP Telephony profile does not.

I contacted BlueRigger about this and they tested for themselves on different hardware and got the same result. BlueRigger says the HFP/HSP Telephony profile works fine with Ubuntu, which they say doesn't use Bluez.

I don't know if this problem is new in Fedora 18, because I didn't get the dongles until after I upgraded from Fedora 17.

I've reported this in Red Hat bugzilla <https://bugzilla.redhat.com/show_bug.cgi?id=905283> and emailed the Fedora test list <http://lists.fedoraproject.org/pipermail/test/2013-February/113598.html> about it; there has been no response to either.

Any suggestions or insights into how to resolve this issue would be appreciated.

Regards,

Jonathan Kamens

Hi,

I sent the below message almost three weeks ago and there have not been any responses that I've seen.

Was this the wrong place for me to report this problem? If so, where should I report it?

You can get a USB Bluetooth dongle for $2.88 on Amazon, so I don't really think cost is an issue, but if it is, then if there is a contributor to the code base who is willing to commit to working on this, I'm happy to mail him/her a dongle.

Jonathan Kamens

Hi Jonathan,

More details on which steps you take to reproduce the problem should help identifying the issue.

Also run "sudo hcidump -w hcidump.dump" while you do these steps and attach the generated hcidump.dump to your email so we can see what's going on.

Ubuntu (as pretty much every Desktop Linux distro, as far as I know) uses BlueZ. The only difference is that distros may use different BlueZ and/or kernel versions and this may cause different levels of hardware support.

My suggestion is for you to download a Live CD/USB for Ubuntu (ideally for the version BlueRigger tested) and confirm yourself it works.

Again, you need to provide more information:

* hcidump log (as explained above)

The information below is also important because not everyone here uses Fedora 18:
* kernel version ("uname -r")
* bluez version ("bluetoothd --version", or at least the package version from the distro).

Best Regards,

Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Hi Anderson,

Thanks for your response.

I posted extensive details in both the bugzilla ticket and the Fedora Testers List message to which I linked; that is why I linked to them. Here's what I put into the Bugzilla ticket:

I have this Bluetooth USB dongle:

Bus 004 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

If I pair my Motorola SF600 headset with my computer using this dongle, then The HSP/HFP Telephony profile doesn't work. More specifically, input works but output does not. At least, I think input is working -- I can see the mic level move in the sound settings control panel when I talk, though I can't play it back because output doesn't work.

In addition, with various combinations of pairing, unpairing, turning on, and turning off, I managed to get things into two interesting states relatively quickly -- one in which the sound settings let me change the profile drop-down but refused to actually switch the headset to that profile, and one in which bluetooth stopped working completely and shutting it off and on wouldn't help -- it would not turn back on. Right now, for example, I connected the headset, went to the sound settings, saw that it was set to the telephony profile, changed it to the high fidelity profile, and then clicked Test Speakers. The speaker testing window should have two buttons, one for left and one for right, but it has only one, as if it's still in telephony mode, and clicking the Test button hangs for a while without doing anything. In short, it's bit of a mess.

I also tested with a second Bluetooth USB dongle; this one, neither input NOR output works when I select the HSP/HFP Telephony profile:

Bus 004 Device 002: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0

I also tested a cheap Bluetiger bluetooth headset with the same result.

In contrast, the HSP/HFP Telephony profile _does_ work with this headset when I pair it to Fedora 18 on my ThinkPad T420i, with this BlueTooth hardware:

Bus 001 Device 021: ID 0a5c:217f Broadcom Corp. Bluetooth Controller

Today, I tested this issue with Fedora 17 64-bit, Ubuntu 12.10 32-bit, and Ubuntu 12.10 64-bit Live CDs. Fedora 17 doesn't recognize the Bluetooth the Bluetooth 4.0 USB dongle at all, and Ubuntu has the same problem as Fedora 18, i.e., my test results contradict BlueRigger's claim that the problem I'm experiencing does not occur in Ubuntu.

I've attached hcidump.dump from when I first pair the headset and connect to it using the Bluetooth 4.0 dongle, switch it to the HSP/HFP profile, and attempt to test sound output, yielding only silence from the headset.

$ uname -r
3.7.9-201.fc18.x86_64
$ bluetoothd --version
4.101
$

Thanks,

Jonathan Kamens

Hi Jonathan,

The SCO connection seems to be established without problems:

    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1

status 0x00 handle 6 bdaddr 00:12:3D:00:48:FD type eSCO Air mode: CVSD

But I cannot see any packets which might be the cause of your problem, so it might be a controller/driver related not PulseAudio problem. You can check what is the current voice settings of the controller by doing:

--
Luiz Augusto von Dentz

On 02/25/2013 04:25 AM, Luiz Augusto von Dentz wrote

I am an experienced software developer but have no experience whatsoever with Bluetooth software development or the Bluetooth protocol, so if you could try to limit the use of, or at least explain, the Bluetooth-related technical terms you are using, that would be helpful. I'm afraid most of the above is gobbledygook to me.

For example, I don't know what the "SCO connection" is. Just to be clear, remember that the behavior I'm experiencing is that my headset works just find in A2DP mode, but not int HSP/HFP mode. If the "SCO connection" is something that would be relevant to both modes, and I don't know whether it is because I don't know these terms, then it's understandable that the dump would show a successful SCO connection; as I mentioned before, in the dump, the headset starts out just fine in A2DP mode and only stops working when I try to switch to HSP/HFP.

I also mentioned before, or at least I think I did, that this same headset works fine with my ThinkPad with built-in (as opposed to USB dongle) Bluetooth hardware, running the same version of Linux as my desktop that isn't working with the dongle, so I had always assumed that it was likely to be a "controller/driver related not PulseAudio problem"; it seems to me that if it were a PulseAudio problem, it wouldn't work on the laptop either.

It is possible that you already know and understand everything I've clarified above, and I'm wasting your time and mine by restating things :-/, but I can't tell whether that's the case because there is so much here about Bluetooth that I don't understand, so I thought it important to make sure everything is clear. I'm sorry if I'm telling you things you already know.

Here is what "hciconfig hci0 voice" prints when I connect to the headset in A2DP mode:

hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:32:77:9C ACL MTU: 1021:8 SCO MTU: 64:1 Voice setting: 0x0060 (Default Condition)
Input Coding: Linear
Input Data Format: 2's complement
Input Sample Size: 16 bit
# of bits padding at MSB: 0
Air Coding Format: CVSD

When I use the Sound Settings applet to switch to HSP/HFP mode and run "hciconfig hci0 voice" again, it says *exactly the same thing*; there is not a single character different in the output? Should it be different?

Here's another interesting (or so it seems to me) piece of information... While the headset was switched into HSP/HFP mode and not working, pidgin generated a sound, which of course I did not hear because the audio wasn't working. When I switched back to A2DP mode, that sound, delayed by several minutes, played through the headset immediately.

Please tell me what more I can do to help debug this further.

Thanks for your help.

Regards,

Jonathan Kamens

FYI, the folks at BlueRigger sent me BTD-300 ("Product=Broadcom Bluetooh 3.0 Device" in usb-devices output, as opposed to "Product=BCM20702A0" for the BTD-400 that wasn't working with HSP/HFP), and it works with HSP/HFP just fine.

This means I've got one USB Bluetooth dongle (the BTD-300) that works with the HSP/HFP profile, and two that don't (the BTD-400 and a cheap Cambridge Research dongle).

In the spirit of supporting open source software, I am willing to mail either or both of the dongles that don't work with HSP/HFP at my expense to anyone on this list who is willing to commit to (a) checking whether this problem still exists with the most recent kernel and bluez code) and (b) debugging and fixing it if it does. You can keep the dongles.

If you are willing to commit to doing these things, send me your mailing address in private email and let me know whether you want just one of the dongles or both of them.

Bonus points if you're willing to specifically make sure it works with Fedora 19, which just went into early testing, but I won't make that a hard requirement for the free dongles. :-)

Thanks,

Jonathan Kamens