No SCO packets while trying to use a Bluetooth headset

No SCO packets while trying to use a Bluetooth headset

[Mario Sanchez Prada]

Hi,

I have a problem with one Bluetooth host (chipset Realtek RTL8723BE) and a Bluetooth headset (Plantronics M50) I've been trying to find a solution for in the last days, without much success yet:

Basically, I can pair the computer with the headset from my Linux machine, connect to it without trouble and select it as a PulseAudio output sink and input source using the HSP/HFP profile, but then I can not hear any sound coming out of the headphones, nor I can capture any sound with the microphone.

For what I can see with hcidump, there seems to be BT traffic when connecting/disconnecting the headset, but no traffic at all once I try to play any sound through them with paplay, nor when trying to use the microphone.

Also, I've observed that everything works fine if I used an external USB Bluetooth dongle in the same machine instead, which produces a slightly different dump with hcidump while connecting to the headset and then, of course, a lot of traffic once paplay is running (lots of SCO packets), which I can't see with the internal chipset.

See the output of lsusb -vvv too for both devices:
 * lsusb for the internal BT device: http://goo.gl/bvBsr7
 * lsusb for the external BT dongle: http://goo.gl/gNT3oZ

Also, here you can see the verbose logs of hcidump -X for both scenarios:
 * Not working (internal chipset): http://goo.gl/34hzQz
 * Working (external dongle): http://goo.gl/HeZPmM

Besides these tests,  I've also ruled out a problem with the actual hardware by checking that the device actually works as expected when booting into Windows 7 and installing the Realtek drivers: no problems there.

Surprisingly, that experiment with Windows provided me an interesting hint: yesterday morning, after using the headset perfectly in Windows, I've rebooted again into Linux and everything worked just fine there at that point, not sure why. I could see SCO packets being transmitted when using the headset both as an output sink and an input source, meaning I could both play sounds through the headphones and capture data with the microphone.

Unfortunately, it stopped working after I powered off the machine and then powered on back again, and I could not reproduce this working scenario either ever since. So, I sadly don't have any log I can attach here now, but the fact that it worked for a while makes me think whether Windows would not have somehow initialized something in the chipset, or even in the headset itself, that persisted across reboots, going away when powering off.

I'm not sure what that really means, just mentioning in case it rings any bell, because I've heard of other situations where some hardware X would work in Linux after rebooting from Windows, so perhaps this could be the case too? Here you have a dump of the USB/HCI traffic in Windows while installing the Realtek driver and connecting to the headset, as a .pcap file that can be examined with Wireshark: http://goo.gl/u6KBy2

I've being studying all this data for a while already, but my knowledge in this matter is still quite limited and so I'd appreciate a few words of direction from someone more experienced to better know how to proceed now.

Of course, feel free to ask for more information if needed.

Thanks in advance,
Mario

PS: I'm using a Debian based distribution with a 3.13.0 kernel and BlueZ 5.23 as packaged by Ubuntu, although I've tried using the latest 5.28 release as well, but that did not get things any better either.

Re: No SCO packets while trying to use a Bluetooth headset

[Mario Sanchez Prada]

Hi again,

Just a quick heads up about the problem mentioned a few days ago (see [1]) to let you know that I've recently (yesterday) tried the latest kernel 3.19 and that did not make any difference either. I've tested this by applying Daniel's patch to add support for the RTL8723BE bluetooth device (see [2]) on top of the v3.19 tag from the kernel git repository, and I also used the latest release of BlueZ and PulseAudio, so the problem seems to be still relevant even with the latest code.

At this point it's not clear to me what the problem could be, so I'd really appreciate any comment that might help fix or improve this situation. Larry Finger, I'm adding you to Cc as I understand you are the go-to person for these drivers, in case you could drop some light on this problem (e.g. perhaps you've seen something similar before?).

Thank you all,
Mario

[1] http://article.gmane.org/gmane.linux.bluez.kernel/58759
[2] http://article.gmane.org/gmane.linux.bluez.kernel/58810

Re: No SCO packets while trying to use a Bluetooth headset

[Luiz Augusto von Dentz]

Hi Mario,

On Tue, Feb 10, 2015 at 12:13 PM, Mario Sanchez Prada
<mario@endlessm.com> wrote:
> Hi again,
>
> Just a quick heads up about the problem mentioned a few days ago (see [1]) to let you know that I've recently (yesterday) tried the latest kernel 3.19 and that did not make any difference either. I've tested this by applying Daniel's patch to add support for the RTL8723BE bluetooth device (see [2]) on top of the v3.19 tag from the kernel git repository, and I also used the latest release of BlueZ and PulseAudio, so the problem seems to be still relevant even with the latest code.
>
> At this point it's not clear to me what the problem could be, so I'd really appreciate any comment that might help fix or improve this situation. Larry Finger, I'm adding you to Cc as I understand you are the go-to person for these drivers, in case you could drop some light on this problem (e.g. perhaps you've seen something similar before?).

I think your controller is not properly setup for SCO over HCI
routing, probably Windows does that so while the controller is still
powered it will work but as soon as you power it down it will loose
these settings. I guess you will need to find what commands these are,
from the logs it seems the Windows driver is doing something that
wireshark cannot decode, perhaps it is not really HCI as it claims to
be.

> Thank you all,
> Mario
>
> [1] http://article.gmane.org/gmane.linux.bluez.kernel/58759
> [2] http://article.gmane.org/gmane.linux.bluez.kernel/58810
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Luiz Augusto von Dentz

Re: No SCO packets while trying to use a Bluetooth headset

[Mario Sanchez Prada]

Hi Luiz,

On 10/02/15 12:05, Luiz Augusto von Dentz wrote:
> [...]
> I think your controller is not properly setup for SCO over HCI
> routing, probably Windows does that so while the controller is still
> powered it will work but as soon as you power it down it will loose
> these settings. 

That makes sense, thanks for the hint, I'll follow that lead and see what I can do with it.

> I guess you will need to find what commands these are,
> from the logs it seems the Windows driver is doing something that
> wireshark cannot decode, perhaps it is not really HCI as it claims to
> be.

I'll take a closer look to those logs again, and probably will try to capture new ones to see if I manage to capture more (and more interesting) traffic that way. So far I've been using USBPcap for that, but perhaps there's a better way to capture BT traffic in Windows, so I'll check that too just in case.

Thanks,
Mario