Hi everybody, I have upgraded to pulseaudio 2.0 through Arch repository and my bluetooth headset is giving me trouble. The headset was working flawlessly before upgrading, I paired it using Gnome Shell's panel and then I could select it as the active sink device in the audio setting. After upgrading, the audio device is not there anymore, even though the headset is paired (I can play/pause music using the play button on it, but music comes from the laptop as I can't select the headset anymore). Looking in systemd's journal at first I found hints similar to: http://wiki.gentoo.org/wiki/Bluetooth_Headset This parameter has never been necessary on my system, though adding Enabled=Socket now changes things in the log, that reports "Failed to load module-bluetooth-device" several times. I've tried deleting .pulse and .pulse-cookie and rebooting, without luck. What is even more strange, is that my headset worked sporadically after removing the paired device from the bluetooth menu, killing the server and repairing the device. This workaround doesn't always do the magic, magic which definitely stops if I reboot. Reverting to the old pulseaudio gives me my headset back, I can connect it and I'll get the audio device without further trouble. I am not sure which logs I should provide, but I'll be glad to come back with as many information as you teach me to do :)
Trying to get some more info, I've run pulseaudio -vvvv and then paired my headset. I'm attaching the output of journalctl that reports the pairing and the failure
Created attachment 62496 [details] Output of pulseaudio -vvvv in journalctl when pairing the headset
I have updated to the master branch of pulseaudio, and now the issue happens from time to time (I'd say 50% of times). Has anybody any idea on what's happening, and how I can help more?
Created attachment 63085 [details] PA log/BT, 5 frames deep, failure connecting BT headset I'm struggling with exact the same issue since quite some time here. Simply turning the BT headset (Sennheiser MM550) on and the sound starts playing on it/it is shown as output device works in probably 1 out of 20 attempts. Most of the time it fails completely; being properly detected + connected by BlueZ, but not properly picked up as sound device by PulseAudio. Attached is a full log (log-level = debug, log-meta = yes, log-backtrace = 5) of the whole connection attempt.
I am still seeing this on a new Samsung Series 9 laptop. Does anybody have any idea on what is going on? Playing the pair/unpair game is not really funny.
I've been using the workaround described here for the past few months with great success: https://bbs.archlinux.org/viewtopic.php?id=165741 This workaround has now stopped working. Instead I can connect the A2DP profile in blueman and the pulseaudio log shows that it registers the new device: D: [pulseaudio] bluetooth-util.c: Device /org/bluez/28447/hci0/dev_00_1D_BA_29_50_D3 interface org.bluez.AudioSink property 'State' changed to value 'connected' D: [pulseaudio] bluetooth-util.c: Device /org/bluez/28447/hci0/dev_00_1D_BA_29_50_D3 interface org.bluez.Audio property 'State' changed to value 'connected' but the device does not appear in pavucontrol. If I connect the headset profile I get similar messages about org.bluez.Headset but the device actually appears and I can send sound to it. The menu then offers me an option to change the profile to a2dp but when I try and do so it fails silently in pavucontrol and the log shows: W: [pulseaudio] module-bluetooth-device.c: Profile not connected, refused to switch profile to a2dp The full log can be found here http://sprunge.us/EHFQ
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/376.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.