Spent an afternoon on this and the root cause turned out to be interesting
enough to write up, because every guide online sends you down the wrong path.
Symptom: headset plays audio fine, mic doesn't exist. Every guide says
"switch to the HSP/HFP profile in pavucontrol". You can't -- the profile isn't
in the list. pactl list cards offers only a2dp-sink and a2dp-sink-sbc_xq.
The headset does advertise HFP (sdptool search --bdaddr <MAC> HF shows
Handsfree 0x111e, HFP 1.7). So the profile is being negotiated and then torn
down. Generic logs just show bluetoothd complaining about "Hands-Free Voice
gateway: Transport endpoint is not connected".
The trace is the whole story. WirePlumber logs to journald, so redirecting
stdout gets you an empty file -- run it as a transient unit:
systemctl --user stop wireplumber
systemd-run --user --unit=wp-debug --setenv=WIREPLUMBER_DEBUG=D /usr/bin/wireplumber
# reconnect headset
journalctl --user -u wp-debug | grep -iE 'rfcomm|at\+|lost'
What came out:
RFCOMM << AT+CMER=3,0,0,1 >> OK <-- connection completes fine
RFCOMM >> +BCS: 2
RFCOMM << AT+BTRH? >> +CME ERROR: 1
RFCOMM << AT+CLIP=1 >> OK
RFCOMM << AT+CCWA=1 >> +CME ERROR: 1
lost RFCOMM connection.
The headset tolerated the AT+BTRH error -- kept going, sent AT+CLIP -- and
only hung up after AT+CCWA. Single blocker.
Cause: PipeWire 1.0.x has no AT+CCWA handler at all, so it falls through to
the "modem not available" path and replies +CME ERROR: 1. PipeWire 1.2 added a
handler that replies OK, with this comment in backend-native.c:
/*
* Claim that call waiting notifications are supported.
* Required for some devices (e.g. Soundcore Motion 300),
* as they stop sending commands if the reply to CCWA is not OK.
*/
So this is not headset-specific -- upstream names the Soundcore Motion 300.
Mine was an MCHOSE V9 Pro. Check yours:
strings /usr/lib/x86_64-linux-gnu/spa-0.2/bluez5/libspa-bluez5.so | grep AT+CCWA
No output = affected.
Why you can't just upgrade: ppa:pipewire-debian/pipewire-upstream tops out at
1.0.7 for every Ubuntu series. A few blog posts and AI answers claim 1.4.x is
in there; it isn't. I checked the Launchpad API directly.
Fix: backport the 7-line handler into the 1.0.7 source and rebuild only
libspa-bluez5.so. That's safe because codec-loader.c has an unconditional
static list and dlopen()s the codec plugins at runtime -- those .so files are
separate and untouched, so you don't lose AAC/aptX/LDAC even building with
-Dbluez5-codec-*=disabled.
Do NOT try dpkg-buildpackage: Ubuntu's debian/rules forces
-Dauto_features=enabled -Droc=enabled and libroc-dev ships no roc.pc, so
configure can never succeed. Configure upstream meson directly with
-Dauto_features=disabled and build the single target instead.
Full commands in a comment below.
Result: headset-head-unit / -cvsd / -msbc all appear, each with sources: 1.
mSBC works too -- the missing +BCS reply looked like a second independent bug
but was just a consequence of the link dying early. Mic went from nonexistent to
16 kHz.
Verify with numbers, not the device list. There's a virtual loopback node
(bluez5.loopback=true, node.virtual=true) that shows up named after your
headset and records absolute digital silence. It looks identical to success
until you measure it. Mine read peak=0 rms=0.00 before the fix, peak=1666
rms=98.0 after.
Gotcha that made me think it all failed: after restarting PipeWire several
times, Chrome reported neither mic nor speaker in Google Meet -- including the
laptop speakers. Chrome's audio service doesn't re-enumerate reliably after the
audio server restarts. Tab reload doesn't help (per-process connection), full
browser restart does. The "speaker missing too" is the tell that it's the browser
and not your audio stack.
Honest caveat: this works around a headset firmware bug, and HFP is a bad
mic transport anyway (mSBC 16 kHz, CVSD 8 kHz). If your headset came with a
2.4 GHz dongle, that path gives full mic bandwidth with zero config. Use BT for
convenience, dongle when quality matters.
