Unable to get HFP wide band voice aka mSBC aka WBS working

[xyzzy]

I’m trying to get the HFP 1.6 wide band audio working with some Bose QC-35 headphones. They do support it. I’m using Linux. It can work in Linux and I’ve done it, just not with the Plugable USB-BT4LE adapter.

pulse-audio has issues with HFP so I’ve switched to using blue-alsa. This software does support the 16 kHz mSBC wide band voice mode when using HFP, as well as the better A2DP codecs.

I’ve gotten it to work on a Pinebook Pro’s built in bluetooth (BCM4345C5 based) with the same software setup.

When using the Plugable adapter (with multiple computers) it fails. A2DP does work (SBC and AAC), and normal 8 kHz CVSD for record and playback works, but sounds poor as expected.

The failure with wideband voice seems to be lack of support in the Plugable adapter for USB alt mode 6, which is used to transfer mSBC data over USB. These log messages appear when attempting to play audio with mSBC when it doesn’t work on the USB-BT4LE and do not appear when using the built-in adapter.

Bluetooth: hci0: Device does not support ALT setting 6
Bluetooth: hci0: urb 00000000d0f6c24f submission failed (90)
Bluetooth: hci0: sending frame failed (-90)

I’ve tried getting the firmware file described on SOLVING HFP/HSP AND A2DP PROFILE ISSUES ON LINUX, and I’ve verified that the kernel driver loads it, but it made no difference.

Does USB-BT4LE support wide band audio in HFP mode?

[plugable_andy]

The Plugable Bluetooth adapter acts as nothing more than a radio for Bluetooth data transfer.

Profile support is entirely dependent on the capabilities of the OS/Bluetooth stack of the device it is plugged into. For Linux, the basic support for the hardware is built into the Linux kernel. All issues relating to audio are the result of issues with BlueZ, Pulseaudio, oFono, and/or ALSA opensource projects.

That being said, there is more to Bluetooth than just profile support. There are some optional modes that don’t have to be present on Bluetooth implementations, such as ‘Bluetooth peripheral mode’, which our adapter does not support. However, our adapter is fully compliant to Bluetooth 4.0 core specifications as validated in the Bluetooth SIG QDID 36434.

Wide band audio is part of the Hands-free Profile version 1.6: https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles#Hands-Free_Profile_(HFP)

The error “Bluetooth: hci0: Device does not support ALT setting 6” is generated by this code: https://github.com/torvalds/linux/blob/master/drivers/bluetooth/btusb.c

Basically, from the looks of this, all the error is saying is that it can’t send packets every 7.5ms, so it will instead alternate packets at 6ms and 8ms. I think the error a red herring for the issue you’re trying to solve.

As noted in the article you linked to regarding the firmware (https://plugable.com/2014/06/23/plugable-usb-bluetooth-adapter-solving-hfphsp-profile-issues-on-linux/) BlueZ 5.x has consistently had issues with HFP/HSP, and the firmware isn’t really applicable to modern Linux distros.

The recommended path to take to get HFP/HSP working is described in this article after clicking ‘Click to Show Linux Information’: https://plugable.com/2017/02/07/bluetooth-audio-problems-cant-get-your-bose-quietcomfort-35-connected-check-here-first/

This may be more difficult to do since you’ve installed this ALSA package, which I have no experience with.

[xyzzy]

In this case, the issue is getting the data from the host system over USB to the adapter. While HFP is part of the host OS’s Bluetooth stack, data still needs to move between the host and the adapter. There are different ways to do this. WBS uses an eSCO pipe, which is different than the old HFP CVSD audio that uses an SCO pipe. Now that the BRCM20702A is owned by Cypress, there’s an actual data sheet available. Check §5.1.6, it specifically describes how WBS needs to be transferred if the PCM interface is being used for audio. Of course that PCM interface doesn’t apply when USB is used, but it still the case that the transferring of the audio data needs to be done in a specific manner.

While you have identified the code producing that error message, your summary of what it does is not correct. If the old SCO CSVD mode is used, then we get the block at line 1704 and alt mode 2, 4, or 5 is used. For eSCO, what we want for WBS, we get the block at line 1712. This attempts to use alt mode 6, since the WBS data rate is different. If alt mode 6 is available, then we select it (line 1716) and turn on usb_alt6_packet_flow (line 1715).

When the isoc mode data is sent later, we’ll get to alloc_isoc_urb() (line 1455). That will check the alt mode (line 1476), and if we are in alt mode 6, it then uses __fill_isoc_descriptor_msbc(). mSBC is the codec used in WBS. In that function on line 1051 is where the alternating 7, 8 ms interval is done to get 7.5 ms average. If we were not in alt 6, then __fill_isoc_descriptor() would be used.

So if things were to work then alt mode 6 would be selected and the data rate would be correct for WBS by using the alt 6 packet length and the 7.5 ms average interval.

You can see this in the Bluetooth Core Specification, Volume 4, §2.1.1, which shows the recommended USB configuration. It recommends alt mode 6 with a 63 byte max packet size and 7.5 ms HCI packet interval for mSBC audio. But the BRCM20702A (or rather, the firmware in it) doesn’t support alt mode 6. It tops out at alt mode 5 on interface 1 with a 49 byte max packet size.

I think maybe the BRCM20702A just doesn’t support WBS over USB. The datasheet feature list has this interesting line, “Supports Wide-Band Speech (WBS) over PCM and Packet Loss Concealment (PLC) for better audio quality”. Note the “over PCM” qualifier attached to WBS support. Is WBS over PCM special enough to get a line all of it’s own, or did they add the “over PCM” because it doesn’t work on the other interfaces?

[plugable_andy]

As I mentioned before, all issues regarding audio over Bluetooth are related to BlueZ, Pulseaudio, oFono, and/or ALSA opensource projects.

There are numerous threads of people encountering bugs with HSP/HFP on Linux, including with wideband audio support. Those issues are not isolated to the BCM20702A0 chip.

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/254
https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/816421

Ultimately BlueZ does not support these profiles directly. On the BlueZ website, they claim oFono provides support for HFP 1.6.

There are steps to potentially use oFono for HFP which can be found on the ArchLinux wiki. As I mentioned before, wideband audio support is specifically part of HFP 1.6. HFP 1.6 is not supported on Windows, and on Linux there are many bugs and interconnected software components to contend with for HFP 1.6 support.

We note in our product information that BlueZ and Pulseaudio are a frequent cause of audio issues, even without introducing wideband audio as a factor.

If you are determined to get wideband audio working, I would recommend reaching out to Linux communities that maintain or specialize in the software components involved with the HFP 1.6 profile.

[xyzzy]

Most issues are related to BlueZ, pulseaudio, and so on. As I said, I’ve gotten this to work with WBS using a different BT adapter. There were many issues to solve to get that far! Mostly with the software you mention. But this issue is with the firmware on the BRCM20702A.

I have checked with communities that specialize in above mentioned software components. General consensus is that the BRCM20702A can not do WBS via the USB interface because the firmware is unable to receive a 60 byte mSBC payload at the proper rate via the eSCO link on USB because it doesn’t support isochronous packets large enough. At least, it certainly can not do it in the manner described in the bluetooth core specification, because it clearly doesn’t support the recommended interface alt mode.

But maybe it has a non-standard method? E.g., Realtek BT adapters have a non-standard feature to get WBS via alt mode 1. However the public CYW20702A datasheet doesn’t go into the firmware at all, so no one knows.

BTW, issues with QC35 and Linux are:

• QC35 support BLE, but can not pair over LE. Linux will try to pair with LE. Turn off LE support in the Bluez config before pairing. And if LE pairing has been tried and failed, clear the QB35’s bt pairing list (hold switch 10+ seconds) or it won’t try to pair again with the same device. Delete the non-functional pairing from Linux’s list too.
• Pulse-audio doesn’t support AAC for A2DP (nor AptX nor LDAC, but neither does the QC35). There is a pulse-audio branch with this, which is available as a package for most distros (pulseaudio-module-bluetooth-freeworld in Fedora, pulseaudio-modules-bt-git in Arch, something else for Ubuntu, etc.). With this, A2DP with AAC or SBC will work perfectly. And you can easily select the codec in the pulse audio config, something MacOS and Windows can’t do.
• While A2DP works with puseladio, HFP doesn’t. Maybe oPhono and phonesim are needed.
• An alternative to pulseaudio for bluetooth audio is blue-alsa, which is more like how Bluez worked before Bluez 5. You can still use pulseaudio, but the QC35 will look like an alsa audio device to pulse.
• With blue-alsa, A2DP with SBC and AAC, and HFP with NBS and WBS work perfectly. No oPhono/phonesim is needed.
• While blue-alsa WBS works fine on UART based BT adapters (typical of built-in bt hardware), there are issues with USB. It’s the USB firmware in the BT adapter and the Linux btusb driver that have these issues.
• blue-alsa will get blocked by SELinux in Fedora 32, and probably other distros when using SELinux too. There’s information about how to fix the SELinux policies to allow it on the blue-alsa issue tracker.