Bugzilla – Bug 1058053
Bluetooth headset stops working after pulseaudio update to 10.99
Last modified: 2017-09-14 09:17:46 UTC
I have a bluetooth headset that worked very well with TW until recently. Physically, it's actually not a classical headset but an add-on turning hearing aids into a headset: http://unitron.com/content/unitron/us/en/professional/hearing-solutions/accessories/hearing-instrument-accessories/udirect-3.html Anyway, it has the same functionality that ordinary bluetooth headsets usually have. Sound output on this device stopped working after a larger zypper dup I did on August 14. Among others, that update included both pulseaudio and bluez updates. I experimented with snapshots and found that the pulseaudio update seems to be the culprit. The the device can be coupled via bluetooth as usual, and it can be set as sink in pulse, but all I hear is a low "feep" tone and then nothing. I hear that "feep" in the good case (pulseaudio 10.0) too, but other sounds are then played normally. The pulse source through the device's mic is not affected.
Trying to clarify what I did to "fix" the problem: I force-downgraded all the below rpms to their 10.0-2.3 counterparts: pulseaudio-10.99.1-1.1.x86_64 pulseaudio-utils-10.99.1-1.1.x86_64 libpulse-mainloop-glib0-10.99.1-1.1.x86_64 pulseaudio-module-bluetooth-10.99.1-1.1.x86_64 libpulse0-10.99.1-1.1.x86_64 libpulse0-32bit-10.99.1-1.1.x86_64 pulseaudio-module-gconf-10.99.1-1.1.x86_64 pulseaudio-bash-completion-10.99.1-1.1.x86_64 alsa-plugins-pulse-1.1.4-1.2.x86_64 pulseaudio-module-x11-10.99.1-1.1.x86_64 pulseaudio-equalizer-2.7.0.2-6.5.noarch pulseaudio-utils-32bit-10.99.1-1.1.x86_64 alsa-plugins-pulse-32bit-1.1.4-1.2.x86_64 pulseaudio-module-lirc-10.99.1-1.1.x86_64 pulseaudio-module-zeroconf-10.99.1-1.1.x86_64 I didn't have the 10.0-2.3 rpm packages around any more, so what I actually did is copy the *contents* of those packages from a btrfs snapshot I had to the current snapshot using cpio copy-pass mode. The full list of changed files wrt a clean pulseaudio 10.99 installation is: S.5....T. c /etc/pulse/daemon.conf ..5....T. /usr/bin/pulseaudio S.5....T. d /usr/share/man/man1/pulseaudio.1.gz S.5....T. d /usr/share/man/man5/pulse-daemon.conf.5.gz ..5....T. /usr/share/pulseaudio/alsa-mixer/paths/analog-input-headset-mic.conf S.5....T. /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf ..5....T. /usr/bin/pacat ..5....T. /usr/bin/pacmd ..5....T. /usr/bin/pactl S.5....T. /usr/bin/padsp ..5....T. /usr/bin/pasuspender ..5....T. /usr/bin/pax11publish S.5....T. /usr/lib64/pulseaudio/libpulsedsp.so S.5....T. d /usr/share/man/man1/pactl.1.gz ..5....T. /usr/lib64/libpulse-mainloop-glib.so.0.0.5 ..5....T. /usr/lib/pulse/gconf-helper S.5....T. /etc/xdg/autostart/pulseaudio.desktop S.5....T. /usr/lib/pulseaudio/libpulsedsp.so Next I'll try to recompile pulse 10.0 cleanly in obs.
The problem described persists if I update pulseaudio to 11.0.
Confirmed with re-built pulseaudio 10.0 on https://build.opensuse.org/project/show/home:mwilck:branches:multimedia:libs The problem is gone.
Created attachment 740206 [details] log file of pulseaudio 11.0 Log file of pulseaudio 11.0 while trying to work with the BT headset. Nothing is heard except a few feeble noises.
Created attachment 740208 [details] log file of pulseaudio 10.0 Log file of pa 10.0, with nice output in headset.
I can't see anything suspicious in these logs so far. PA 11.0 doesn't error out; it just doesn't seem to play sound in a way that the headset could transform into something actually audible.
I also have a Twiek6: http://www.audiovox.de/produkte/twiek6-2/ It seems not to work with PA11 on TW, either.
I've played around with various hints found on the web, neither has had an effect: load-module module-bluetooth-discover headset=native in default.pa resample-method = trivial in daemon.conf (tried other settings as well).
disabling module-suspend-on-idle also had no effect (already thought so, because the module was already enabled with 10.0 as well)
Upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=102660
As noted in the upstream bug, here's a workaround for PA 10.99 and 11.0: load-module module-bluetooth-discover autodetect_mtu=false The default for "autodetect_mtu" is likely to change to "false" in 11.1.