Public bug reported:
[ Impact ]
Bluetooth headsets that require the HFP Audio Gateway to answer AT+CCWA with
"OK"
cannot use their microphone on Ubuntu 24.04. The headset establishes the HFP
service-level connection, receives "+CME ERROR: 1" in reply to AT+CCWA=1, and
immediately tears down the RFCOMM link. As a result no headset-head-unit profile
is ever created and the microphone does not appear at all -- only A2DP profiles
are offered, so the usual "switch to the HSP/HFP profile" advice cannot be
applied because the profile does not exist.
Upstream PipeWire fixed this in the 1.2 series by adding an explicit AT+CCWA
handler in spa/plugins/bluez5/backend-native.c that replies "OK", with a comment
naming the Soundcore Motion 300 as an affected device:
} else if (spa_strstartswith(buf, "AT+CCWA=")) {
/*
* 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.
*/
rfcomm_send_reply(rfcomm, "OK");
The handler is absent in 1.0.7 and present in 1.2.7 and later. Since noble ships
the 1.0.x series and no >=1.2 package exists for it (the
ppa:pipewire-debian/pipewire-upstream PPA tops out at 1.0.7 for every Ubuntu
series), affected users currently have no option other than patching and
rebuilding the bluez5 SPA plugin themselves.
[ Test Plan ]
1. Pair a headset with this firmware behaviour (verified with an MCHOSE V9 PRO;
upstream also names the Soundcore Motion 300). The headset advertises HFP but
not HSP -- "sdptool search --bdaddr <MAC> HS" returns nothing -- so there is
no fallback profile.
2. Connect it and run: pactl list cards
Expected before the fix: only "off", "a2dp-sink" and "a2dp-sink-sbc_xq"
profiles; no "headset-head-unit".
3. Capture the RFCOMM dialogue:
systemctl --user stop wireplumber
systemd-run --user --unit=wp-debug --setenv=WIREPLUMBER_DEBUG=D \
/usr/bin/wireplumber
# reconnect the headset
journalctl --user -u wp-debug | grep -iE 'rfcomm|at\+|lost'
Before the fix the trace ends with:
RFCOMM << AT+CCWA=1
RFCOMM receive command but modem not available: AT+CCWA=1
RFCOMM >> +CME ERROR: 1
lost RFCOMM connection.
4. Apply the upstream AT+CCWA handler, rebuild, reconnect, and re-run
"pactl list cards".
Expected after the fix: headset-head-unit, headset-head-unit-cvsd and
headset-head-unit-msbc all present and available, each with "sources: 1".
5. Confirm the microphone actually captures audio (a virtual loopback node can
otherwise appear and record pure silence, which is indistinguishable from
success in a device list):
timeout 8 parecord --device=bluez_input.<MAC> --file-format=wav \
--channels=1 --rate=48000 /tmp/mic.wav
Before: peak=0, rms=0.00. After: clearly non-zero (peak=1666, rms=98.0
here).
[ Where problems could occur ]
The change is a single new else-if branch in the AG-role AT command dispatcher
in
spa/plugins/bluez5/backend-native.c. It only alters the reply to AT+CCWA, which
1.0.x currently answers with an error because it has no handler at all.
Replying "OK" claims support for call-waiting notifications without a modem
backend, so a device could in principle expect subsequent +CCWA unsolicited
result codes that never arrive. In practice AT+CCWA=1 only enables notifications
for calls, and PipeWire is not a telephony gateway, so no call ever exists to
notify about. This is the behaviour upstream has shipped since 1.2 across the
1.2 and 1.4 series.
Regression risk is limited to HFP/HSP Bluetooth audio. A2DP playback is not
touched. Devices that already worked send AT+CCWA and simply receive "OK"
instead of an error, which is strictly more permissive than the current
behaviour.
[ Other Info ]
Affected package versions:
pipewire 1.0.5-1ubuntu3.3 (noble, noble-updates, noble-security)
pipewire 1.0.7-3~ubuntu24.04 (ppa:pipewire-debian/pipewire-upstream)
Both lack the handler; "strings" on
/usr/lib/x86_64-linux-gnu/spa-0.2/bluez5/libspa-bluez5.so finds no AT+CCWA.
System: Ubuntu 24.04.4 LTS, Intel AX201 Bluetooth, bluez
5.72-0ubuntu5.5.
Note that rebuilding the Ubuntu source package to test this is currently not
possible without extra work: debian/rules forces
-Dauto_features=enabled -Droc=enabled, and libroc-dev ships no roc.pc, so
dh_auto_configure fails with:
../src/modules/meson.build:627:10: ERROR: Dependency "roc" not found,
tried pkgconfig and cmake
I worked around this by configuring upstream meson directly with
-Dauto_features=disabled and building only the
spa/plugins/bluez5/libspa-bluez5.so target. That may be worth a separate bug.
Secondary observation: with the CCWA fix in place, mSBC negotiation also starts
working on this headset. Beforehand the headset never answered the AG's
"+BCS: 2" codec selection, which looked like an independent mSBC bug; it was
actually a consequence of the link being torn down before negotiation finished.
The microphone runs at 16 kHz after the fix instead of falling back to 8 kHz
CVSD.
** Affects: pipewire (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2162010
Title:
Bluetooth headset microphone never available: HFP link dropped because
AT+CCWA is answered with +CME ERROR (fixed upstream in 1.2)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2162010/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
