[BT] PW doesn't seem to use LDAC, even though BT endpoint supports it
Bluetooth Radio, Bluetooth Headset, Desktop Environment, Distribution, Version (Bluez, Kernel, and PipeWire):
Radio: Intel Wireless 8265 / 8275
BT Headset: SMSL SU-9 DAC (BT Mode). Amazon product page. TL;DR: DAC with support of a myriad BT codecs, including aptX+HD, LDAC, AAC, SBC, etc.
DE: KDE 5.22
Distro: Arch Linux
Bluez: 5.59-2
Kernel: 5.12.14
Pipewire:
pipewire 1:0.3.31-1
pipewire-media-session 1:0.3.31-1
pipewire-pulse 1:0.3.31-1
Description of Problem: This very specific BT DAC recently had a firmware update, and now it doesn't seem to play along with Pipewire. Pairing will succeed, but there seems to be something wrong when PW sends a BT command (namely SetConfiguration). This seems to prevent Pipewire from successfully creating a playback sink.
BT behavior somehow changed between firmware revisions:
Old firmware: After pairing, PW sends BT command SetConfiguration such that both parties agree upon a BT codec (LDAC). Codec discovery is previously done using the Discover command, which, to my best understanding, advertises supported codecs/roles. Since this DAC supports LDAC, it'll be used as first choice. Everything literally "just works".
New Firmware: BT Packet exchange between my PC and DAC seems to be pretty much identical with both (DAC) firmware revisions, until PW sends SetConfiguration command: this time it'll default to SBC, even though LDAC seems to be "advertised" in the Discover response issued by the BT endpoint. The response to this command fails miserably, which has 2 possible causes:
-
This DAC was poorly designed. However, Android's bluetooth stack seems to handle this properly (it can even cycle through all the supported codecs just fine). Since SBC supports two sampling rates (48/44.1), I changed bluez5.default.rate accordingly - it didn't make any difference.
-
There's something wrong in PW. PW doesn't seem to retry to negotiate another supported BT codec such as LDAC/aptX/AAC after failure - it just seems to yeet itself for no apparent reason and thus will be unable to establish a BT sink to play audio. Probably PW doesn't have a robust BT fallback mechanism for BT codecs? It seems strange to me that it actually tried SBC instead of LDAC in the first place, as it did with the old firmware.
Final notes: I am by no means a bluez expert/dev, and the packet captures for sure need a more thorough inspection.
How Reproducible: 100% given you have this DAC with the latest firmware revision.
Steps to Reproduce:
- Pair to BT endpoint using any BT frontend. KDE's bt manager, bluetoothctl or blueman.
- Connect to BT endpoint: it will fail.
Actual Results: Failure when connecting to endpoint because of SET_CONFIGURATION request rejected: Configuration not supported (41).
Expected Results: Pipewire should use LDAC to connect to the BT endpoint. It should "just work" as it did with the old firmware revision.
I'll try to reproduce this issue on a live Fedora ISO. I am attaching BT packet captures, pw-media-session output as well as bluetoothd journal output.
Additional notes: bad-48: New firmware, packet capture with bluez5.default.rate set to 48000 KHz.
bad-441: New firmware, packet capture with bluez5.default.rate set to 44100 KHz.
good: Old firmware.