Bluetooth audio reliability issues -- paired+connected, but no sound

Hello there,

I'd like to enquire about reliability issues I've had on LE with Bluetooth audio output.

What happens is that the first time I use a Bluetooth headset all is well, but once I've finished watching whatever and switch off the headset to put it on charge the LE audio output seems to break. The symptom is that all future audio output is completely silent. This includes HDMI, analogue, and Bluetooth outputs, even when cycling through them to try and cause whatever audio backend LE uses to restart. It also includes when the original headset is reconnected fully.

Well, I say silent, but not completely. UI and media audio doesn't play at all, but the "null" background sound is still audible, including the audio you hear with the "Send low volume noise" setting.

So far the only workarounds I've come across is either hard-reboot LE or cycle through half a dozen (or more) media files. -- The latter option will sometimes cause the LE audio output to kind of restart itself, in that a loud burst of backlogged UI sounds play in parallel, and the media's audio plays as normal until the next time the Bluetooth headset is disconnected.

This isn't quite the same as LE Settings Addon Crashes, though getting the Plugable USB Bluetooth adapter solved that. -- Using a USB Bluetooth adapter also solved a slightly different issue I experienced with the Pi's built-in Bluetooth device whereby audio output would play fine over Bluetooth for a random duration (anything from a few seconds to 10ish minutes) then go completely silent as per my current issue.

Would there be any recommendations for stabilizing Bluetooth audio output, or would this be a real issue?

This issue seems to impact LE versions 9.0 and 9.2 equally. My Pi is model 3 B+. My Kodi log is here: 2019-12-09 19:06:49.560 T:1937637392 NOTICE: ---------------------------------- - Pastebin.com

If you require further details please let me know.

Thanks for reading.

Thanks for the additional information panuh.

• I've not noticed any patterns or consistency with the media asset being played, and to be honest it didn't cross my mind. -- Most of my videos are h264 or mpeg. All the ones I've found impacted are from 576i (PAL) upto 1080p.
• I've not done any overclocking on my Pi. I can't really fit a fan on there as I have the TV hat in place, though the firmware overheating icon doesn't show up.
• I also find that LibreELEC randomly reports no Bluetooth devices.

I would agree with the possibility of the onboard Bluetooth device not being powered enough, which is what led me to purchase the Plugable USB adapter. I'm not sure how well powered the primary USB hub is on the Pi 3. I do wonder if using a USB adapter really disables the onboard Bluetooth device?

I'm currently using 3 of the USB ports, the other two used are for a Logitech wireless keyboard/mouse, and a 128 GB flash memory stick. Perhaps if I move the Bluetooth adapter to a pair of ports on its own it'd help, as I believe USB root hubs tend to come as a pair of ports. Otherwise I think an external USB hub with its own power source would be required to resolve that.

Thanks too for pointing out the "bluetoothd" service. -- I'll give that a manual restart and see if that matters when this problem occurs.

--

Update: Looks like the service is just "bluetooth" rather than "bluetoothd". Upon checking its status I found:

● bluetooth.service - Bluetooth service
   Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor preset: disabled)
   Active: inactive (dead)
Condition: start condition failed at Sat 2019-12-14 17:41:03 GMT; 1s ago
           └─ ConditionPathExists=/storage/.cache/services/bluez.conf was not met

Restarting the service didn't work. However after doing `touch /storage/.cache/services/bluez.conf` then restarting bluetooth it gives a more promising status:

● bluetooth.service - Bluetooth service
   Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor preset: disabled)
   Active: active (running) since Sat 2019-12-14 17:41:18 GMT; 1s ago
 Main PID: 11575 (bluetoothd)
   Status: "Running"
   Memory: 2.2M
   CGroup: /system.slice/bluetooth.service
           └─11575 /usr/lib/bluetooth/bluetoothd

Dec 14 17:41:18 adam-pi systemd[1]: Started Bluetooth service.
Dec 14 17:41:18 adam-pi bluetoothd[11575]: Bluetooth daemon 5.50
Dec 14 17:41:18 adam-pi bluetoothd[11575]: Starting SDP server
Dec 14 17:41:18 adam-pi bluetoothd[11575]: kernel lacks bnep-protocol support
Dec 14 17:41:18 adam-pi bluetoothd[11575]: System does not support network plugin
Dec 14 17:41:18 adam-pi bluetoothd[11575]: Bluetooth management interface 1.14 initialized
Dec 14 17:41:18 adam-pi bluetoothd[11575]: Endpoint registered: sender=:1.6 path=/MediaEndpoint/A2DPSource
Dec 14 17:41:18 adam-pi bluetoothd[11575]: Endpoint registered: sender=:1.6 path=/MediaEndpoint/A2DPSink
Dec 14 17:41:18 adam-pi bluetoothd[11575]: Endpoint registered: sender=:1.6 path=/MediaEndpoint/A2DPSource
Dec 14 17:41:18 adam-pi bluetoothd[11575]: Endpoint registered: sender=:1.6 path=/MediaEndpoint/A2DPSink

I'll see how well audio works shortly!

Update:

I got an externally powered USB hub. However the Plugable Bluetooth adapter appears to not be detected at all through it. (I used command `lsusb -t` to check.) -- This wasn't directly related to this primary thread topic though, as the USB hub was USB 3, but the Plugable Bluetooth adapter was only USB 1.1 compatible. (I simply chained in a passive USB 2.0 hub between the USB 3.0 hub and USB 1.1 devices to fix that.)

Anyway, it was now important to switch off the internal device and switch to the external device. You'll need a terminal to do this (e.g. over SSH.) Unfortunately this is quite a manual process though I'm welcome to suggestions to automate this.

Use command `hciconfig` to discover the logical Bluetooth device addresses and take particular note of the "Bus" value to determine which is internal and which is external. In my case "hci1" is the internal device, shown by the bus "UART". This is a logical address though, so it may appear as "hci0" for you. -- Your external device will have the bus showing as "USB". (Mine was "hci0".)

To switch off the internal device do `hciconfig hci1 down`, and bring up the external device to `hciconfig hci0 up`. Check the status of these with just `hciconfig`, which should then look similar to this:

# hciconfig
hci0:   Type: Primary  Bus: USB
        BD Address: 5C:F3:70:99:29:95  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING PSCAN ISCAN
        RX bytes:83454 acl:150 sco:0 events:5814 errors:0
        TX bytes:8409806 acl:9984 sco:0 commands:292 errors:0

hci1:   Type: Primary  Bus: UART
        BD Address: B8:27:EB:CC:39:58  ACL MTU: 1021:8  SCO MTU: 64:1
        DOWN
        RX bytes:2403 acl:0 sco:0 events:162 errors:0
        TX bytes:9246 acl:0 sco:0 commands:162 errors:0

Its very likely at some stage that LibreELEC will try and bring it back up, particularly if you restart the Bluetooth service in LibreELEC settings. A crude workaround for this is to use CRON to bring down the internal Bluetooth device every minute. Make sure the CRON service is enabled in the LibreELEC settings. Then in your terminal press CTRL+L to clear the buffer, then do command `crontab -e` to edit your crontab via the NANO text editor.

Append the following line to the buffer:

* * * * * hciconfig hci1 down && hciconfig hci0 up

Press CTRL+O to save that, then CTRL+X to exit the editor. You may need to restart the CRON service by using command `systemctl restart cron`, but I'm not sure if that's required. -- Now every minute you will ensure that the internal device is shut down, and the external device is up.

Now that your external device is active you need to pair up your sound device manually, because the LibreELEC Bluetooth control panel only works with the internal device.

1. Set the Bluetooth scanning mode: `hciconfig hci0 piscan`
   (This will make your external Bluetooth device discoverable.)
2. Set the Bluetooth pairing mode to simple (PIN-less): `hciconfig hci0 sspmode 1`
3. Open the Bluetooth control tool: `bluetoothctl`
   (This is a separate utility and any command you now submit will not appear in the Bash `history`.)
   
   1. Now ensure your sound device is switched on AND in the "pairing" state.
   2. Start scanning: `scan on` OR list already known devices: `devices`
   3. Find your sound device, e.g. "Device 00:08:2A:F3:B7:98 Vigorun Y3"
   4. Stop scanning: `scan off`
   5. Pair your sound device: `pair 00:08:2A:F3:B7:98`
   6. Trust your sound device (for PIN-less pairing): `trust 00:08:2A:F3:B7:98`
   7. Connect to your sound device: `connect 00:08:2A:F3:B7:98`
   8. Exit the Bluetooth control tool: `exit`

Your Bluetooth sound device should now show up as a PULSE output via LibreELEC's system settings.

At this point Bluetooth sound worked as normal, though I've not fully tested how reliable this is in the long run, or whether manual steps to connect up again are required.

Update (again):

I've since turned off my headset for charging. When I turned it on it immediately connected up with the external Bluetooth device without any commands necessary.

There is still the issue of needing to stop/start media half a dozen times to get LibreELEC's sound component to kind of restart itself, but this is significantly better than using the internal Bluetooth device.

A couple of weeks further I thought it'd be worth sharing my experience to date on this issue.

The problem happens the vast majority of the time your headset reconnects even with an externally powered USB Bluetooth adapter, be it after a full power off, or automatic sleep. -- The external adapter doesn't solve the issue completely, but is just rather better than using the internal adapter. (Not getting hard UI crashes with an external adapter.)

The biggest inconsistency is resuming sound after reconnecting, which is by far the biggest annoyance of this. Sometimes the following will resolve it as a one off:

• Seeking to random different points in the video. (Going ahead in large steps has worked more often for me.)
• Fully stopping playback and restarting the video. (Press the Stop button so you exit to the menu.)
• Switching to a different media type, e.g. start a music file.
• Issuing Bluetooth reconnect commands manually via a terminal.

These are very much in the moment though, so sometimes you'll need to cycle through those steps for 10+ minutes, in which case you might as well do the only solid resolution -- hard reboot.

I'd be very much interested to hear a comment from a developer or veteran of LibreELEC for some further insight into the problem, and what I could do to resolve it completely.

I guess this issue is rare, but for what its worth I've decided to ditch the shoddy Bluetooth implementation and instead use a 3.5mm to Bluetooth transmitter.

Bluetooth 5.0 Transmitter / Receiver, TaoTronics 2-in-1: Amazon.co.uk: Electronics

(Plenty of alternative products available.)

This means LibreELEC sends its audio via HDMI in a very typical way. (I have mine set to HDMI + Analogue.) The TV is then responsible for

redirecting the input audio to its 3.5mm headphone jack, then finally the above transmitter to send the audio to a Bluetooth headset.

Advantages are the audio reliability issues are completely gone. Resuming after being idle for a while is instant without any buffering problems. The audio delay can also be reset to zero as this approach seems to be much less laggy.

So far the only disadvantage is the buttons on your Bluetooth headset (if they have any) will obviously no longer be able to control (pause etc) the playback, but if you've got a CEC capable remote then this is satisfactory.

I was using HDMI audio to my TV with the product I bought but it turned out to be unreliable tat. The signal just dropped out all the damn time. Sent it back for a refund and got one of these instead:

Golvery Bluetooth Transmitter with Digital Optical and: Amazon.co.uk: Electronics

I use the optical TOSLINK port on my TV to that, then it does a boss job of transmitting that to bluetooth earphones.

It's also a good option if your TV has a 3.5mm headphone port. That will work just as well.