Forumite Members › General Topics › Tech › Makers & Builders › Raspberry Pi › A Pi3 Bluetooth Speaker Problem -SOLVED!
- This topic has 10 replies, 5 voices, and was last updated 7 years, 8 months ago by
Ed P.
-
AuthorPosts
-
June 15, 2018 at 7:43 am #21903
I have a Kitchen Pi project that aesthetics and usability dictate using both Wifi and a Bluetooth Speaker in conjunction with a Chromium Browser.
This is a recipe for disaster with a Pi3 setup.
a) Chromium is both a memory and an I/O hog
b) The integrated Bluetooth and Wifi on a Pi3 are not usable as they share common interfaces, and this appears to be buggy
c) After a period of time the Wifi will crash out, bringing down the Bluetooth in an uncorrectable buffer underrun.
Three measures are needed to fix these issues:
a) Chromium itself will cause BlueAlsa buffer underruns when using an SD card. Simply replacing the SD card with a USB stick helps but not enough. The only real solution to this part of the problem is to use a cheap SSD (64GB is more than enough for most purposes). This addition also avoids the early failure of the SD card caused by Chromium’s high volume of cache writes.
b) Turn off either the onboard Bluetooth or the onboard Wifi and replace with a USB dongle. To do this a simple addition to /boot/config.txt is all that is required using one of the following:
dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-btc) Wifi crashing is more contentious as many dispute the logic of why the solution works. Snake oil is one phrase that has been used. It appears that the cause is somewhere in the wlan0 kernel code for wlan power saving, and the cure is to turn off power saving at the source by adding iwconfig wlan0 power off to /etc/rc.local:
The snake oil comment comes from some bloggers as the Pi turns off power management at kernel level. However, this patch is probably continually active and consumes too many clock cycles which consequently results in the Bluetooth Speaker not being ‘fed’ fast enough. This causes Bluetooth underruns/crashes. The etc/local addition by-passes the buggy kernel patch.
June 15, 2018 at 9:12 pm #21939The only real solution to this part of the problem is to use a cheap SSD (64GB is more than enough for most purposes). This addition also avoids the early failure of the SD card caused by Chromium’s high volume of cache writes.
If you have a NAS drive, depending on how it’s formatted, you can use that with either a native filesystem (ext4) to store the Pi OS, or a loopback device if it’s, e.g. NTFS formatted. The difference between the two is that the native filesystem rootfs size is only limited by the drive size, whilst the loopback device is a fixed size image.
However, you don’t need a dedicated drive in either case.
I have three PIs. One boots from a directly connected 1Gb USB HD, with all the FS storage on it (It’s currently an experiment for work to provide secure filesharing for clients to get around GDPR. It will be re-purposed at some point.
PI 2 and 3 boot from a shared NAS connected to Pi 2. The connected 500Gb HD is a NAS share, with a partition to boot Pi 2, and a folder that Pi 3 gets rootfs from.
/boot is still on the respective sdcards, but since /boot is rarely written to, it’s hardly a problem at all.
Arch Linux, on a Ryzen 7 1800X, 32 GB, 5 (yes -5) HDs inc 5 SSDs, 4 RPi 3Bs + 1 RPi 4B - one as an NFS server with two more drives, PiHole (shut yours), Plex server, cloud server, and other random Pi stuff. Nice CoolerMaster case, 2 x NV GTX 1070 8GB, and a whopping 32" AOC 1440P monitor.
June 16, 2018 at 11:09 am #21963Unfortunately the usb solution is too slow. This is really a Chrome hog problem, but what happens is that Chrome gets into a problem writing to the usb cache which results in the Bluetooth speaker going into an unrecoverable under-run state. A cobbled fix(non-ideal) is to use yet another usb stick as dedicated swap.
I agree a Eth0 solution would be ideal but unfortunately the kitchen location does not have an Ethernet socket anywhere near it.
June 19, 2018 at 8:26 pm #22080You marked this solved, without saying how. Give us a clue 🙂
Arch Linux, on a Ryzen 7 1800X, 32 GB, 5 (yes -5) HDs inc 5 SSDs, 4 RPi 3Bs + 1 RPi 4B - one as an NFS server with two more drives, PiHole (shut yours), Plex server, cloud server, and other random Pi stuff. Nice CoolerMaster case, 2 x NV GTX 1070 8GB, and a whopping 32" AOC 1440P monitor.
June 20, 2018 at 7:07 am #22093To completely fix it I guess we really need a rehash of the Pi mobo and action by Broadcom (unlikely). We probably have to wait for Pi4 to do all this as the Pi foundation only uses hardware which is stable and available for many years. (i.e. far from cutting edge). Software changes in Raspbian are also required such as a rewrite of bluealsa and/or elimination of the dependency on alsa
However the cobbled fixes I gave do eliminate the main issues of unacceptable stuttering/crashing by the Bluetooth audio system.
June 20, 2018 at 8:44 am #22097Would a wifi plug solve it? That way, the Pi believes it’s still on Eth0, but in reality, it’s on WiFi. Solves the issue of no ethernet within the kitchen.
"Everything looks interesting until you do it. Then you find it’s just another job" - Terry Pratchett
June 20, 2018 at 4:50 pm #22102It might, but it would lose a kitchen socket
June 20, 2018 at 5:17 pm #22104I should perhaps have said that this problem is most noticeable when trying to use the Pi to listen to BBC Radio. TV seems OK, but Chrome treats audio-only streams differently.
June 21, 2018 at 12:26 am #22118It might, but it would lose a kitchen socket
Something like this?
https://www.amazon.co.uk/Pro-Elec-Gang-Adaptor-Switch-CAB5186/dp/B00LGWNJZO/
June 21, 2018 at 1:00 am #22120Something like this? https://www.amazon.co.uk/Pro-Elec-Gang-Adaptor-Switch-CAB5186/dp/B00LGWNJZO/
You can get a 3 gang plug in, or a 500mm trailing version in Poundland. I’ve had 4 of them in use for several years so there’s now’t wrong with the quality.
--
Regards
wasbitRig 1: Optiplex 3050 SFF
Rig 2: Asus ROG G20CB (rebuilt wreck)
Rig 3: HP Elitebook 8440PDear Starfleet, hate you, hate the Federation, taking Voyager. - Janeway
June 24, 2018 at 10:36 am #22239Bah! Broadcom has released a buggy update for Raspbian and wlan0 still crashes fairly frequently. The iwconfig wlan0 power off addition fixes one Broadcom bug, but others remain.
Broadcom are investigating together with Raspberry Pi people but nothing so far. .You can follow the action or inaction on this GitHub thread.
From the thread in my case it may be the crappy wifi output from BTHubs that initiates the Broadcom crash as one person reported that the crash occurs when wifi is lost.
-
AuthorPosts
- You must be logged in to reply to this topic.
