-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[5.59] A2DP sink profile is unavailable on newly added/paired devices #157
Comments
Try with the following patch: |
I have the same issue as OP. |
@abhijeetviswa thanks for confirming it, we might have to release 5.60 sooner. |
@Vudentz thanks for the quick fix, the patch works. Tested with it and without it (just a commit before) to be sure, |
I have the same issue as OP. Just posting it here to register that this might not be something rare. |
Attempt1: Bluez-GitI had the exact same problem, and the fix by installing bluez-git in Arch Linux temporarily worked:
Upon next reboot, I had the exact same problems connecting as before. I could pair/trust, but not connect. Attempt 2: Downgrade to 5.58
But it would still only pair/trust and not connect Attempt 3: Replace pulseaudio with pipewire (fixed!)Pipewire replaces both pulseaudio and pulseaudio-bluetooth:
In my case I believe the problem was simply pulseaudio-bluetooth (Edit: I fixed some formatting of this post for better readability.) |
I hoped this would solve the issues I'm having with my AirPods Pro, however it got even worse. Here's how my connection-procedure looked like with bluez from arch/extra repo:
After that the connection would be established automatically, however there's only HSP/HFP would be available. As soon as I switch the profile to A2DP (within KDEs bluetooth-settings), the output would get deactivated. Now, that I have installed bluez-git, I can still connect to the AirPods Pro with the same procedure as above, however, the headphones aren't registered as audio-sink anymore. Is this to be expected with Apple hardware or am I hitting another bug here? |
@tim-hilt , you may need to rm /var/lib/bluetooth folder and repair the your AirPods, according to above. |
@joakim-tjernlund thanks for the reply, but unfortunately this doesn't change the behavior for me. |
Just another bug I would guess, perhaps not bluez but pipewire/pulsaudio or kernel |
Thanks for the hint! Will investigate this further. |
I'm also affected by this one. Downgrading the bluez to 5.58 now. |
Downgrading bluez to 5.58 and removing |
@tim-hilt , perhaps check out https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1328 |
Encountered this on Fedora 34 with bluez 5.59 and Jabra 75T earbuds. Steps below to fix it. Downgrade bluez, in Fedora 34, this will install bluez 5.56
Next, remove the bluetooth cache. Be aware that it will also remove all your paired bluetooth connections.
Reboot Re-pair with the device Some folks above have been able to update bluez after pairing with the older version, and have kept A2DP functionality. I found that if I updated to the latest bluez, I would lose A2DP after a few reboots or restarts of bluetooth. But your experience may be different. If you want to lock your version of bluez and wait for a fix, you can do so with
|
I am also using arch linux, but I did not have to change from pulseaudio to pipewire. you only needed to
|
Sorry to be a pain but is there an estimated date for release |
I hit the same issue with AirPods, downgrading to 5.58 and removing the bluetooth folder fixed it. I hope this will be fixed in the next update? |
To give an update from my side: The issue I saw before was fixed by swapping out I also had problems with the firmware of my bluetooth-card (Intel AX200). I could listen to music, but experienced a very small sound-droput every approx. 6 seconds. I actually timed that and the 6 second delta was surprisingly uniform. Apparently the issues got fixed in In my case, I just installed Now I don't have any disconnects, deactivations or dropout, but I'm experiencing low volume levels on the AirPods and none of the suggested fixes from the Arch Wiki (running bluetoothd with @joakim-tjernlund actually pointed me in the right directions to solve the audio-artifacts over at pipewires GitLab. I had them on all of my bluetooth-headphones, although with different characteristics. Thanks again Joakim! |
@tim-hilt I used a smartphone to increase my AirPods audio level, then reconnect them to the PC and they somehow were louder. Maybe that works? It seems that the AirPods have their own "volume" that is synced on iOS but not Linux? If I try with AirPods Max, I can adjust the volume on the headphones + the system volume separately. I had to turn them to maximum volume to be able to use the Linux controls in normal levels. |
@Infinytum oh wow, that's some interesting insight! However, I couldn't reproduce this behavior unfortunately. I set the volume to different extremes on the iPhone, but didn't notice any change in volume level on the laptop. This holds true for my ThinkPad T14S, as well as my ThinkPad X1 Carbon 5th gen. Other than that, the volume-dropouts started reappearing on the T14S, whereas I didn't notice any audio-artifacts on the X1 Carbon. Strange... |
This is how i deal with the AirPods volume: #17 (comment) I use a script that iterates through a few of the possible d-bus paths and tries setting the remote volume to the maximum value of '127' for the MAC address of my AirPods. I mapped the script to a keyboard shortcut and that's good enough as a workaround for me. |
@tim-hilt , Intel AX2xx just got new FW at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/ |
@joakim-tjernlund man, I really should watch those logs more regularly! Updated, rebooted, works again. |
@SebiderSushi thanks for the tip! Again, that are some "exotic" recommendations that I've hadn't heard of before. I just blindly copied and executed your script and it then printed
it might stem from the fact, that I don't even use Let's not spam this thread any further, as it gravitates towards my AirPods-issues rather than being concerned with the original bluez-issue. Is there a different way to reach you? You can also find some contact-information about myself in my GitHub-profile, if you want to reach out to me. Thanks again for the tip so far! |
also seeing this with Sony XM4 on Fedora 34, These hadn't been paired before. [1] #157 (comment) |
Can confirm this with my new Poly Voyager 8200 UC on Fedora 34. Workaround #157 (comment) has helped me too. |
I am experiencing this issue as well on my Sony WH-1000XM3, running Fedora Silverblue (34). @Vudentz would it be possible to get a hot fix release for this issue, it seems very widespread. |
Firstly: This is the first time I can remember having Bluetooth broken like this in Linux. Bluetooth is generally excellent on Linux, thanks to this project Huge thanks to everyone at working on Bluez. 👏 👍 However, Bluetooth audio has been broken for over two weeks on all Linux distributions that have upgraded to Bluez 5.59, including (but probably not limited to) Fedora and Arch. Having broken Bluetooth audio is bad in most times, but it's compounded by the need to use headphones for many people to be able to do video calling for remote work, remote schooling, calling friends and family, and so on, in the age of the pandemic. It would be excellent to have a new release with the fix, either as a full release or as a hotfix. @jonkoops: I'm also using my Sony WH-1000XM3 on Fedora Silverblue 34. At first, I did a workaround by adding a wacky USB audio device that exports as Bluetooth (needed for a Nintendo Switch) and paired to that until I found this issue and did an override for Silverblue. (I couldn't do a rollback, as I had to do a fresh reinstall two weeks ago.) For Silverblue, I had to hunt down builds of the previous version of Bluez, download RPMs (x86_64), and do an override for the packages that are installed by default: FWIW: There's a Fedora bug at https://bugzilla.redhat.com/show_bug.cgi?id=1976795. |
@garrett I agree. The regression is serious enough that warrants an immediate hot fix release. Hopefully we see one soon 🤞 |
The downgrade also solved the issue for me. |
For me using bluez-git from the AUR and removing |
For me this bug happens even though I am using pipewire and not pulseaudio. |
@Toadfield: Yep, everyone on Fedora 34 is on PipeWire by default and are hit by this bug too. There's a big enough mix of people above in this issue using PipeWire and PulseAudio that I think we can safely say this issue is really about Bluez, irrespective of PipeWire or PulseAudio. Hopefully there will be an official fix soon, as most people definitely won't find this bug and know to downgrade Bluez... they'll just have broken Bluetooth audio like we all have had for the past few weeks. |
When will the fix be released? |
My god, it's such a blessing that I've found this issue. I've been pulling my hair for the past few days because my bluetooth would just not cooperate at all. I honestly didn't think it could've been an issue with bluez, as I'm always taking the blame on myself when something doesn't work haha. Using |
5.60 has been released: |
https://build.opensuse.org/request/show/903983 by user seife + dimstar_suse add bluez-5.59-0388794dc5fdb73a4ea.diff, fixes a2dp on newly paired devices, bluez/bluez#157 (forwarded request 903982 from seife)
5.60 has indeed resolved the problem and has been rolled out to the latest Silverblue. I did however still need to remove the |
Note that in some circumstances the user must delete /var/lib/bluetooth if 5.59 created cache files affected by bluez issue 157[0]. I don't know if it's acceptable to do this in post_install(). I will note that archlinux did not remove /var/lib/bluetooth[1]. [0] bluez/bluez#157 [1] archlinux/svntogit-packages@03e8179
This is critical. I was having these problems and only when I removed the |
In some circumstances, the user must delete /var/lib/bluetooth if 5.59 created cache files affected by bluez issue void-linux#157 [1]. We chose not to automate this procedure, since it would also delete user configurations. Instead, we will keep an INSTALL.msg until the next version bump. [1] bluez/bluez#157
In some circumstances, the user must delete /var/lib/bluetooth if 5.59 created cache files affected by bluez issue #157 [1]. We chose not to automate this procedure, since it would also delete user configurations. Instead, we will keep an INSTALL.msg until the next version bump. [1] bluez/bluez#157
I was not seeing the A2DP profile even after following all these steps. My issue was that there was a Sorry if this isn't the place for it, but maybe this will help somebody else out. |
I also had this problem and it showed pactl load-module module-bluetooth-discover
Failure: Module initialization failed All I have to do as mentioned was to: sudo systemctl stop bluetooth
rm -rf /var/lib/bluetooth
sudo systemctl start bluetooth
bluetoothctl |
Seems like we've discovered a new bug related to ServiceRecords/Endpoints discovery on 5.59. After pairing my headphones for the first time on bluez 5.59, I couldn't get A2DP profile working (it would be marked as unavailable).
After some experimentation I've found out that downgrading to 5.58 works, but only if I remove
/var/lib/bluetooth
folder before pairing the headphones again.After a little bit of digging, I've narrowed the issue down to the cache file for the headphones. The cache file created by 5.59 seems to have some of the services/endpoints not listed properly. Here's the cache file created by 5.58, where A2DP works fine:
and here's the same file created on 5.59, where A2DP is reported as unavailable:
There are differences in both
ServiceRecords
andEndpoints
sections.Please not that this bug is visible only on 5.59 if you're pairing the device for the first time, or if you manually remove
/var/lib/bluetooth
folder. If the folder contains the cache file for your device created by one of the olderbluez
(5.58 or older), A2DP profile will work fine, even if you remove and re-pair the device. It only doesn't work if the cache file doesn't exist yet (if 5.59 version creates the file).You can read more info about how we've discovered the bug here: https://bbs.archlinux.org/viewtopic.php?pid=1978509
The text was updated successfully, but these errors were encountered: