Though past-posts here might lead one to believe that it's Linux-wireless that has been my major bug-bear over the years, truth is, it hasn't been so for a long time. Seems, somewhere along the line, the Linux Devs got their shit together - that, or Intel finally started supplying drivers that actually work, who the hell knows.
Anyway, it's Linux Bluetooth that has been driving me demented for the longest time. Pretty much from the 'beginning' actually, when I switched over to Linux, 2008 or thereabouts. Sure BT has always kinda worked, but you try mix-&-matching and you're in for a whole world of pain.
My setup involves three BT-enabled PC's, but only one BT-headset. Surely it's not unreasonable to expect pretty much seamless usage of said headset across all three pc's? That has always been my expectation at any rate, but 12+ years of experience to the contrary had proven this to be wishful thinking. This isn't just a Linux problem either - though I can't speak for current M$ offerings, Win7 is just as bad.
Confined to a single pc, BT works pretty well - once your BT-headset has been paired with the pc, you can generally expect hassle-free performance. The problems begin when you then try using the same headset with a different pc (which works fine) and then switching back. Trying to get the already-paired headset to re-connect with the pc can be a nightmare. With Win7 it is in fact easier to just re-pair the device. Linux is generally more amenable, particularly if you're working with Blueman, but still way more hassle than it has any right to be.
The question is, WHY??? Much as I loathe Android, it manages to make re-connecting to an already-paired device a doddle - so why can't Linux do the same? While I don't have an explanation, I at least have figured out a reasonably hassle-free means of getting my BT-headset re-connected.
Incidentally, almost all of the BT problems I've experienced revolve around 'Audio-sink' connections - 'headset' connections seem to work flawlessly, but are of no use when just trying to listen to music. The fact that this is so and that my M-Pow headset has a built-in mic, and therefore chooses a 'headset' connection by default has been a source of constant irritation, salting the wound, you might say.
The re-connection problems all stem from the Pulseaudio module 'module-bluetooth-discover', at least on my setup. If you are unable to connect to your headset via a 'Audio-sink' connection, but a 'Headset' connection attempt works fine, issue the following command from the terminal;
pactl load-module module-bluetooth-discover
If it spits back a number, that means the module was not loaded, so another attempt to connect with a 'Audio-sink' connection will almost certainly succeed. Why 'module-bluetooth-discover' unloads itself is open to question, but one thing I have discovered is that any problem with Pulseaudio itself will result in 'module-bluetooth-discover' being purged. Thing is, Pulseaudio is so integrated into Linux, that any Pulseaudio crash would likely go unnoticed by the user anyway - the OS immediately reloads Pulseaudio in the event of a crash. There are in fact many forum threads devoted to trying to STOP Pulseaudio being reloaded in this fashion - not an easy thing to do apparently. But I digress...
What I've opted to do is, rather than trying to fix Linux, instead, if a 'Audio-sink' connection fails, just run the following Bash script;
#!/bin/bash
pulseaudio --kill
kill -9 $(ps -e | grep blueman-manager | awk '{print $1}')
pactl load-module module-bluetooth-discover
sleep 5
pactl load-module module-bluetooth-discover
All this does is, kill Pulseaudio (it will restart itself) and Blueman (Blueman often hangs when it experiences a re-connection issue, it will also self-start). Then load the Pulseaudio module 'module-bluetooth-discover' TWICE, with a 5sec delay in between. For some unknown reason, while loading it just once 'works', it immediately unloads itself! The 5sec delay between reloading is also crucial - setting 1,3 etc. delays, result in a failed attempt at reloading.
Edit.
I've been playing with a brand-spanking new Deepin 20.2 release, Bluetooth specifically, and once again, I'm underwhelmed. In a nutshell, BT SUCKS with bells on! Frankly, I can't believe BT is this bad with current Linux versions.
Nothing that I've commented on above applies to Deepin 20.2's problems - for instance, the 'bluetooth-module-discover' is correctly & intelligently reloaded whenever it is either deliberately removed, or when (on Mint 17.3 at least) some other BT-related crash causes it to be purged. Yet despite this, nothing works properly, with the exact same problem described above, being the order of the day! Whereas Mint 17.3 now always reconnects to my BT headset, no matter what it had been paired & connected to previously - that is, once the above Bash script is run - Deepin BT absolutely refuses to reconnect, where the headset had been last connected to another machine.
So, although both OS's display identical re-connection problems, the underlying reason for their failure seem to be completely different. Bloody infuriating.
Although I commented on M$ Windows 7's similarly shabby BT performance above, I neglected to mention that at least one available Windoze application fixes the problem - IVT BlueSoleil - Bluetooth done properly! I've only just discovered that they also do a Linux version, which is intriguing. Unfortunately, for whatever reason, their site is down at the moment, so no link available. Oddly, they still don't have a 'secure' https URL which is strange - and maybe part of the reason their site seems to have been hacked.
Edit.
One last comment on this. As I've mentioned already, BT on my Raspberry PI 3B+ is practically unusable, providing the worst BT experience of the lot. I've just discovered though, after trying it with an old (BT 2.0) CSR BT stick, that bluetooth works perfectly well! Trying out the same old BT stick on both my laptop & Linux/Win7 Desktop computers, both of which sport Intel 7260AC Wireless/BT cards, the experience, while not perfect, is markedly better. And if memory serves, integrated BT with Qualcomm cards was equally awful.
So it's beginning to appear that combined Wireless/BT cards are generally a bad idea. In fact I've noticed that on my laptop, when I introduce the CSR BT dongle to the mix, Intel BT does not seem at all happy. Bluemon generally refuses to allow switching between the Intel & CSR adapters, often crashing Wireless itself, and requiring either a reboot or a Suspend/Resume if I'm lucky, in order to restart it. Given that I'm using native Intel BT drivers with both my machines, I guess I can only conclude that if the almighty Intel can't get their own cards to work properly, what hope is there for the rest of us. Sigh.
