Created attachment 374246 [details] system log of bluetoothd -d My headset, a Plantronics Voyager Legend, was working fine until the recent upgrade of bluez and pulseaudio. The current versions are: net-wireless/bluez-5.15:0::gentoo USE=cups -debug obex readline (-selinux) -systemd (-test) net-libs/libbluedevil-2.0_rc1:4::gentoo net-wireless/bluedevil-2.0_rc1:4::gentoo media-sound/pulseaudio-5.0:0::gentoo USE=X alsa asyncns -avahi bluetooth caps dbus -doc -equalizer gdbm glib -gnome gtk ipv6 jack -libsamplerate -lirc (-neon) orc (-oss) qt4 -realtime ssl (-system-wide) -systemd tcpd udev webrtc-aec -xen (-test) abi_x86: (-32) (64) -x32 sys-kernel/gentoo-sources-3.12.13 I also have Enable=Socket in /etc/bluetooth/audio.conf, disabling did not have any effect. This bug is similar to https://bugs.gentoo.org/show_bug.cgi?id=506024, but I do not get a segfault. The behaviour is as follows: device is off, bluetoothd is started > bluetoothctl [NEW] Controller 00:1A:7D:DA:71:09 nowhereland-0 [default] [NEW] Device 48:C1:AC:C2:4F:94 PLT_Legend starting pulseaudio (i.e. pavucontrol) [CHG] Controller 00:1A:7D:DA:71:09 UUIDs has unsupported type switching on the device and trying to connect manually [bluetooth]# connect 48:C1:AC:C2:4F:94 Attempting to connect to 48:C1:AC:C2:4F:94 Failed to connect: org.bluez.Error.NotReady I have attached a bluetoothd -d log, but when running the above "connect" command in bluetoothctl once, there is no output and when running it again only this line: bluetoothd[3960]: src/device.c:connect_profiles() /org/bluez/hci0/dev_48_C1_AC_C2_4F_94 (all), client :1.28 Then I switch the device off again, but again there is no reaction in the log files. --- In the configuration file default.pa and system.pa of pulseaudio-4.0 there was the following part, which was removed in version 5.0: .ifexists module-dbus-protocol.so load-module module-dbus-protocol .endif When keeping it in the config files, switching the device on makes bluetoothctl output the following: [CHG] Device 48:C1:AC:C2:4F:94 Connected: yes [CHG] Device 48:C1:AC:C2:4F:94 Connected: no and the "unsupported type" message disappears. Also it is now possible to connect manually: [bluetooth]# connect 48:C1:AC:C2:4F:94 Attempting to connect to 48:C1:AC:C2:4F:94 [CHG] Device 48:C1:AC:C2:4F:94 Connected: yes Connection successful [CHG] Device 48:C1:AC:C2:4F:94 Modalias: bluetooth:v0055p0115d005D and system log shows: bluetoothd[2319]: /org/bluez/hci0/dev_48_C1_AC_C2_4F_94/fd1: fd(19) ready kernel: input: 48:C1:AC:C2:4F:94 as /devices/virtual/input/input28 In this case pavucontrol shows the PLT Legend headset device as sink, but not as source and under "configuration" it only allows the selection of "A2DP Sink" or "Off". --- After downgrading to bluez-4.101-r8, libbluedevil-1.9.4, bluedevil-1.3.2 and pulseaudio-4.0 everything works again as before. I have pulseaudio sink, source and pavucontrol shows the third option "HSP/HFP". Autoconnecting also works in this setup. The system log shows in this case: bluetoothd[2321]: Badly formated or unrecognized command: AT+XEVENT=USER-AGENT,COM.PLANTRONICS,PLT_Legend,115,34.93,c8b5b35479ef224081dc6a3cb508a9e0 kernel: input: 48:C1:AC:C2:4F:94 as /devices/virtual/input/input8 bluetoothd[2321]: Badly formated or unrecognized command: AT+BIA=0,0,0,1,1,1,0 when switching the device on.
As I read in pulseaudio-5.0 looks like that module is now not loaded by default on purpose: * Removed module-dbus-protocol from the default configuration But, if I understand correctly, it is neither working even loading that module, right? Did you also try with bluez-5.17?
Yes, that is correct. Loading the module only allows manual connecting to the headset and playback, but not recording. I tried bluez-5.17 now, but it did not work any better than 5.15. On the contrary: now loading module-dbus-protocol does not change anything at all.
Can you report this issue to pulseaudio upstream? (for now I would report to pulseaudio) -> bugzilla.freedesktop.org Then post the link here to let us track the issue. I was looking to all major distributions about how they were packing pulseaudio and bluez and looks like we don't do anything "special" :/ Thanks
I did not think the error message Failed to connect: org.bluez.Error.NotReady could be pinned on pulseaudio, so I searched for information about it, and stumbled on this thread: http://comments.gmane.org/gmane.linux.bluez.kernel/41737 It seems, that the bluetooth controller is not powered up automatically anymore. But it is possible to enable power and connect to the device manually: [bluetooth]# power on [bluetooth]# connect 48:C1:AC:C2:4F:94 So there are the following issues: 1) The bluetooth controller is not powered on automatically. 2) When the headset is powered on, it will connect and immediately disconnect again. This is probably a bug. I will attach the output of btmon. 3) Pulseaudio-5.0 does not support HSP/HFP with bluez-5, i.e. using the microphone on the headset is not possible. This is explicitely said in the release notes: http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/5.0/ As far as I can see, Gentoo requires bluez-5 for pulseaudio-5. Thus when installing pulseaudio-5[bluetooth], at the very least, there should be a warning about the missing functionality. For me of course it would have been even better, had it not been marked stable in the first place. I am not sure how widespread issue 1) is. Maybe with Gnome or KDE it does not arise. But I use the lightweight Awesome WM, so having to enable bluetooth manually everytime is quite cumbersome. It would be nice to have a workaround here.
Created attachment 374336 [details] btmon output during headset powering on
(In reply to Bodo Graumann from comment #4) > 3) Pulseaudio-5.0 does not support HSP/HFP with bluez-5, i.e. using the > microphone on the headset is not possible. > This is explicitely said in the release notes: > http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/5.0/ Probably we should be enabling both bluez-4 and bluez-5 in pulseadio with USE=bluetooth. As far as I can tell, pulseaudio connects to bluez over dbus instead of linking to the library, so it should to be able to support both bluez versions without recompiling.
(In reply to Alexandre Rostovtsev from comment #6) > (In reply to Bodo Graumann from comment #4) > > 3) Pulseaudio-5.0 does not support HSP/HFP with bluez-5, i.e. using the > > microphone on the headset is not possible. > > This is explicitely said in the release notes: > > http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/5.0/ > > Probably we should be enabling both bluez-4 and bluez-5 in pulseadio with > USE=bluetooth. As far as I can tell, pulseaudio connects to bluez over dbus > instead of linking to the library, so it should to be able to support both > bluez versions without recompiling. That makes me wonder why upstream even added that configure switch then. When I looked to it seems like the configure switch end up causing changes in how things were compiled from Makefiles. Also, I have seen that even in openSuSE, thay only rdepend on the older version, they need to detect the bluez version used at builtime. Then, I am unsure what would occur when pulseaudio-5 gets built against bluez-4 and, later, user updates to bluez-5 but pulseaudio is not recompiled
Umm, just after sending the comment I thought that maybe we could use subslots rdeps to force pulseaudio recompilation each time bluez is updated/downgraded... or am I missing something?
+*pulseaudio-5.0-r1 (27 Apr 2014) + + 27 Apr 2014; Pacho Ramos <pacho@gentoo.org> +pulseaudio-5.0-r1.ebuild: + Support bluez-4 too (#505474, #506744, 506024) +
