A Pi3 Bluetooth Speaker Problem -SOLVED!

Forumite Members General Topics Tech Makers & Builders Raspberry Pi A Pi3 Bluetooth Speaker Problem -SOLVED!

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #21903
    Ed PEd P
    Participant
      @edps
      Forumite Points: 39

      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-bt

      c) 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.

       

      #21939
      D-DanD-Dan
      Participant
        @d-dan
        Forumite Points: 6

        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.

        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.

        #21963
        Ed PEd P
        Participant
          @edps
          Forumite Points: 39

          Unfortunately 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.

          #22080
          D-DanD-Dan
          Participant
            @d-dan
            Forumite Points: 6

            You 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.

            #22093
            Ed PEd P
            Participant
              @edps
              Forumite Points: 39

              To 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.

              #22097
              DrezhaDrezha
              Participant
                @drezha
                Forumite Points: 0

                Would 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

                #22102
                Ed PEd P
                Participant
                  @edps
                  Forumite Points: 39

                  It might, but it would lose a kitchen socket

                  #22104
                  Ed PEd P
                  Participant
                    @edps
                    Forumite Points: 39

                    I 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.

                    #22118
                    TipponTippon
                    Participant
                      @tippon
                      Forumite Points: 0

                      It might, but it would lose a kitchen socket

                      Something like this?

                      https://www.amazon.co.uk/Pro-Elec-Gang-Adaptor-Switch-CAB5186/dp/B00LGWNJZO/

                      #22120
                      wasbitwasbit
                      Participant
                        @wasbit
                        Forumite Points: 245

                        Something 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
                        wasbit

                        Rig 1: Optiplex 3050 SFF
                        Rig 2: Asus ROG G20CB (rebuilt wreck)
                        Rig 3: HP Elitebook 8440P

                        Dear Starfleet, hate you, hate the Federation, taking Voyager. - Janeway

                        #22239
                        Ed PEd P
                        Participant
                          @edps
                          Forumite Points: 39

                          Bah! 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.

                        Viewing 11 posts - 1 through 11 (of 11 total)
                        • You must be logged in to reply to this topic.