blueman
blueman copied to clipboard
Bluetooth earbuds auto-disconnects after some time, does not happen on GNOME bluetooth.
blueman: 2.3.1 BlueZ: 5.64 Distribution: Linux Mint 21 (based on Ubuntu 22) Desktop environment: Cinnamon
- [x] I have consulted the Troubleshooting page and done my best effort to follow.
Issue
I have a pair of Galaxy Buds Live headset. When I manually pair the device for the first time, it works. When put the buds back in the case and take them out, it auto connects (blueman does show the device is connected), but no audio is emitted. After some 40 seconds, the device gets disconnected.
The connection has been marked as trusted.
Fix so far Once the buds power on, I have to wait till it gets connected, wait till it disconnects on its own, then manually connect. This is very annoying.
Expected behavior The headset / buds should auto connect and stay connected. Audio should work after connection.
Experience on GNOME bluetooth On GNOME based desktop environment (I tried Pop_OS and Ubuntu budgie, both based on Ubuntu 22) the expected behavior occurs. The buds auto-connect when I take them out of the case and stays connected.
Logs:
- journalctl --unit=bluetooth -f
- cat /var/log/syslog | grep -i blue
- blueman-applet --loglevel debug
blueman-applet 03.27.35 DEBUG Base:60 do_g_properties_changed: /org/bluez/hci0/dev_10_E4_C2_82_C8_54 {'Connected': True} blueman-applet 03.28.06 DEBUG Base:60 do_g_properties_changed: /org/bluez/hci0/dev_10_E4_C2_82_C8_54 {'Connected': False}
- Device properties as in blueman log
blueman-applet 03.27.10 DEBUG Base:60 do_g_properties_changed: /org/bluez/hci0/dev_10_E4_C2_82_C8_54 {'Address': '10:E4:C2:82:C8:54', 'AddressType': 'public', 'Name': 'Galaxy Buds Live (C854)', 'Alias': 'Galaxy Buds Live (C854)', 'Class': 2360324, 'Icon': 'audio-headset', 'Paired': True, 'Trusted': True, 'Blocked': False, 'LegacyPairing': False, 'Connected': False, 'UUIDs': ['00001101-0000-1000-8000-00805f9b34fb', '0000110b-0000-1000-8000-00805f9b34fb', '0000110c-0000-1000-8000-00805f9b34fb', '0000110d-0000-1000-8000-00805f9b34fb', '0000110e-0000-1000-8000-00805f9b34fb', '0000111e-0000-1000-8000-00805f9b34fb', '00001200-0000-1000-8000-00805f9b34fb', 'a23d00bc-217c-123b-9c00-fc44577136ee', 'b4a9d6a0-b2e3-4e40-976d-a69f167ea895', 'e7ab2241-ca64-4a69-ac02-05f5c6fe2d62', 'f8620674-a1ed-41ab-a8b9-de9ad655729d'], 'Modalias': 'bluetooth:v0075pA013d0001', 'Adapter': '/org/bluez/hci0', 'ServicesResolved': False}
- Kernel information
Linux src 5.15.0-46-generic #49-Ubuntu SMP Thu Aug 4 18:03:25 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
To me the bluetoothd log looks like it fails to set up the streams between the audio server (presumably pulseaudio) and the device. The discover command times out. You should check the pulseaudio logs as well.
blueman has no stake in that process and gnome-bluetooth should not have any either. You can try blueman on Gnome as well and you can try without blueman in Cinnamon (if the device is trusted, blueman's agent should not be required for bluetoothd to handle the incoming connection).
I'm rather sure that it's not the desktop environment that makes the difference. All three systems are based on Ubuntu 22.04, right? So they should have similar Linux kernels and versions of BlueZ and pulseaudio but there must be a crucial difference.
The only thing I can think of is pipewire's pulse layer is causing issues. But does mint use pipewire?
@infirit Yes, Linux Mint 21 uses Pipewire.
I don't think so and cannot find any reference. Otherwise, that would totally be a crucial difference between Linux Mint and the other Ubuntu 22.04 based systems. (Note: I interpret "use pipewire" as shipping it as the default audio server - of course you can install it from the repository.)
Linux Mint 21 uses pipewire by default, Mint 20 did not.
sayantan@src:~$ cat /etc/os-release
NAME="Linux Mint"
VERSION="21 (Vanessa)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 21"
VERSION_ID="21"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=vanessa
UBUNTU_CODENAME=jammy
sayantan@src:~$ uname -a
Linux src 5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51:15 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
sayantan@src:~$ apt list --installed -q | grep pipewire
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
gstreamer1.0-pipewire/jammy,now 0.3.48-1ubuntu1 amd64 [installed]
libpipewire-0.3-0/jammy,now 0.3.48-1ubuntu1 amd64 [installed]
libpipewire-0.3-modules/jammy,now 0.3.48-1ubuntu1 amd64 [installed]
pipewire-bin/jammy,now 0.3.48-1ubuntu1 amd64 [installed]
pipewire/jammy,now 0.3.48-1ubuntu1 amd64 [installed]
sayantan@src:~$ ps -e | grep pipewire
1117 ? 00:00:00 pipewire
@cschramm could you let me know how to get pulseaudio logs? I see different instructions on the internet.
Oh wow. Surprising that this change is not mentioned in the release notes (while blueman is 🫣) but then it's rather clear that it's PipeWire that causes your problem. pulseaudio logs are pointless / non-present then, of course (would be something like journalctl --user -u pulseaudio.service
).
PipeWire logs should be something like journalctl --user -u pipewire --user -u wireplumber --user -u pipewire-pulse
. Troubleshooting instructions are available at https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#bluetooth.
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2082 seems somewhat similar to this.
Thanks for looking into it, I will check the logs and get back.. Interesting to note that Pop_OS 22 or other GNOME / Ubuntu 22 based distros also use Pipewire. Wonder what's wrong in Mint.
It's true for Pop!_OS 22.04. Ubuntu Budgie is going to switch in 22.10, so if you tested with 22.04 it was pulseaudio. I still don't think that Linux Mint switched (reference seems to be https://github.com/linuxmint/linuxmint/issues/336), maybe you did? :smile: Pop!_OS 22.04 ships custom / newer versions (0.3.56-0pop1 in the repositories) which could explain that you do not encounter your issue there.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.