Summary: | net-wireless/bluez-5.15 and media-sound/pulseaudio-5.0: missing features – autopoweron, autoconnect and HSP/HFP | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bodo Graumann <mail> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | pacho, sound |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
system log of bluetoothd -d
btmon output during headset powering on |
Description
Bodo Graumann
2014-04-04 13:00:05 UTC
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) + |