On Pi3 B and B+ choppy sound

[gearhead]

I thought this was a wifi/BT interference problem, but even with BT turned off, I get choppy sound. It plays a bit at a time then cuts out then comes back. I do not get this with the same packages and install on a Pi2 with an old BT dongle... On teh Pi2 it works fine and no choppiness
The journal shows:

Apr 04 22:24:06 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: ../src/shared/ctl-client.c:108: Connecting to socket: /var/run/bluealsa/hci1
Apr 04 22:24:07 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: ../src/shared/ctl-client.c:108: Connecting to socket: /var/run/bluealsa/hci1
Apr 04 22:24:07 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: ../src/shared/ctl-client.c:135: Subscribing for events: 111
Apr 04 22:24:07 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:522: Creating PCM worker BC:FF:EB:39:E0:5E
Apr 04 22:24:07 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:711: Starting main loop
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:594: Received new connection: 13
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:607: New client accepted: 13
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:632: +-+-
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:594: Received new connection: 14
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:607: New client accepted: 14
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:632: +-+-
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:594: Received new connection: 15
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:607: New client accepted: 15
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:632: +-+-
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:327: PCM requested for BC:FF:EB:39:E0:5E type 0x81
Apr 04 22:24:07 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:632: +-+-
Apr 04 22:24:07 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: ../src/shared/ctl-client.c:108: Connecting to socket: /var/run/bluealsa/hci1
Apr 04 22:24:07 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: ../src/shared/ctl-client.c:397: Requesting PCM open for BC:FF:EB:39:E0:5E
Apr 04 22:24:07 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:355: Starting PCM loop
Apr 04 22:24:11 gusrune bluealsa[276]: /usr/bin/bluealsa: bluez.c:1363: Signal: PropertiesChanged: org.bluez.MediaTransport1: State
Apr 04 22:24:11 gusrune bluealsa[276]: /usr/bin/bluealsa: ba-transport.c:560: State transition: 0 -> 1
Apr 04 22:24:11 gusrune bluealsa[276]: /usr/bin/bluealsa: ba-transport.c:683: New transport: 16 (MTU: R:672 W:1008)
Apr 04 22:24:11 gusrune bluealsa[276]: /usr/bin/bluealsa: bluez.c:1363: Signal: PropertiesChanged: org.bluez.MediaTransport1: State
Apr 04 22:24:11 gusrune bluealsa[276]: /usr/bin/bluealsa: ba-transport.c:560: State transition: 1 -> 2
Apr 04 22:24:11 gusrune bluealsa[276]: /usr/bin/bluealsa: ba-transport.c:105: Created new IO thread: A2DP Sink (AAC)
Apr 04 22:24:11 gusrune bluealsa[276]: /usr/bin/bluealsa: io.c:661: Starting IO loop: A2DP Sink (AAC)
Apr 04 22:24:13 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:15 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:17 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:19 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:21 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:23 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:25 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:27 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:29 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:32 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:34 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:36 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:38 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:40 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:42 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:44 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: io.c:695: BT socket has been closed: 16
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ba-transport.c:884: Exiting IO thread: A2DP Sink (AAC)
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: bluez.c:723: Endpoint method call: org.bluez.MediaEndpoint1.ClearConfiguration()
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ba-transport.c:296: Freeing transport: A2DP Sink (AAC)
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ba-transport.c:838: Closing PCM: 17
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:626: Sending notification: 100 => 14
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:632: +-+-
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:537: Client closed connection: 15
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:632: +-+-
Apr 04 22:24:46 gusrune bluealsa-aplay[1398]: /usr/bin/bluealsa-aplay: aplay.c:307: Exiting PCM worker BC:FF:EB:39:E0:5E
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:537: Client closed connection: 13
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:632: +-+-
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:537: Client closed connection: 14
Apr 04 22:24:46 gusrune bluealsa[276]: /usr/bin/bluealsa: ctl.c:632: +-+-
Apr 04 22:24:46 gusrune systemd[1]: bluealsa-aplay@BC:FF:EB:39:E0:5E.service: Succeeded.

[gearhead]

Also, if you know, why does the B3+ have a non-use-able hci0? I have a B3 and a B3+ set up and am trying this on them. Both of these pis are using the onboard bluetooth. Both are using the same image with the same packages installed. This strange non-accessible hci0 means I need to specify hci1 for my bluealsa service files. Any idea what is going on?
Pi B3:

# systemctl | grep blue
sys-subsystem-bluetooth-devices-hci0.device                                                                             loaded active plugged   /sys/subsystem/bluetooth/devices/hci0                                                 
bluealsa.service                                                                                                        loaded active running   BluezAlsa proxy                                                                       
bluetooth.service                                                                                                       loaded active running   Bluetooth service                                                                     
brcm43438.service                                                                                                       loaded active running   Broadcom BCM43438 bluetooth HCI                                                       
system-bluealsa\x2daplay.slice                                                                                          loaded active active    system-bluealsa\x2daplay.slice                                                        
bluetooth.target                                                                                                        loaded active active    Bluetooth 

Pi B3+

# systemctl | grep blue
sys-devices-platform-soc-3f300000.mmc-mmc_host-mmc1-mmc1:0001-mmc1:0001:3-bluetooth-hci0.device                                      loaded active plugged   /sys/devices/platform/soc/3f300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:3/bluetooth/hci0
sys-subsystem-bluetooth-devices-hci0.device                                                                                          loaded active plugged   /sys/subsystem/bluetooth/devices/hci0                                                    
sys-subsystem-bluetooth-devices-hci1.device                                                                                          loaded active plugged   /sys/subsystem/bluetooth/devices/hci1                                                    
bluealsa.service                                                                                                                     loaded active running   BluezAlsa proxy                                                                          
bluetooth.service                                                                                                                    loaded active running   Bluetooth service                                                                        
brcm43438.service                                                                                                                    loaded active running   Broadcom BCM43438 bluetooth HCI                                                          
system-bluealsa\x2daplay.slice                                                                                                       loaded active active    system-bluealsa\x2daplay.slice                                                           
bluetooth.target                                                                                                                     loaded active active    Bluetooth  

[gearhead]

I note the same result on PiZero (armv6) and also on Pi B3 (armv6). This is only with the onboard bluetooth dongle.
usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred

[borine]

I have a rpi zero W and a rpi 3B+, both with minimal Raspbian Stretch Lite systems installed. Neither has a device "hci1", the on-board bluetooth is hci0, and bluealsa-aplay works flawlessly on both.

Since systemd gets its devices from udev, you should look at your udev config to find out why systemctl reports 2 bluetooth devices and what exactly is hci0 on your system.

I think the best place to look for answers would be on a forum for your specific system (you don't say what system it is) as neither issue looks like it is directly related to bluealsa, and other users of that system may have already experienced and fixed the issue.

[gearhead]

@ borine - Good advice. I'll do some checking on the boards. I am running Arch Linux. I'll look into udev a bit more.
In /etc/udev/rules.d, there are only 2 files

/etc/udev/rules.d/raspberrypi.rules 
SUBSYSTEM=="vchiq|input", MODE="0777"
KERNEL=="mouse*|mice|event*",  MODE="0777"
/etc/udev/rules.d/99-a2dp.rules 
KERNEL=="input[0-9]*", RUN+="/srv/http/command/a2dp-autoconnect"

The a2dp-connect is this:

#!/bin/bash
# at each BT connection/disconnection start/stop the service bluealsa-aplay
function log {
        sudo echo "[$(date)]: $*" >> /var/log/a2dp-autoconnect
}
BTMAC=${NAME//\"/}

if [ `echo $BTMAC | egrep "^([0-9A-F]{2}:){5}[0-9A-F]{2}$"` ]
then
       if [ $ACTION = "remove" ]
       then
             log "Stop Played Connection " $BTMAC
             ifconfig wlan0 up
             systemctl stop bluealsa-aplay@$BTMAC
       elif [ $ACTION = "add" ]
       then
             log "Start Played Connection " $BTMAC
             ifconfig wlan0 down
             systemctl start bluealsa-aplay@$BTMAC
       else
             log "Other action " $ACTION
       fi 
fi

Neither image lists any other problems in journal or dmesg when the audio problems are apparent, It just plays a bit then stops then plays a bit more. It also does not appear in the journal that the device is connecting and disconnecting until I actually disconnect from the phone. This script works fine with a BT dongle on either B1 or B2 image.

It is strange to me that the same B2/3 (armv7h) image works perfectly on my Pi2 which has an old BT dongle and hiccups on a B3 and B3+ with onboard BT. Similarly, the same B1 (armv6h) image works perfectly with a BT dongle on the B+ and has this hiccup with the Zero with onboard BT.

[gearhead]

digging a bit further... My alsa-utils is 1.1.8. I am running the latest git of bluealsa 1.4.0.r9.g1557602
This is the error:
bluealsa-aplay[1432]: /usr/bin/bluealsa-aplay: aplay.c:469: An underrun has occurred

The B3 adapter lists as:

# btmgmt info
Index list with 1 item
hci0:	Primary controller
	addr B8:27:EB:D7:82:70 version 7 manufacturer 15 class 0x040000
	supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy configuration static-addr 
	current settings: powered bondable ssp br/edr le secure-conn 
	name gretarune
	short name 
hci0:	Configuration options
	supported options: public-address 
	missing options: 

The Pi2 list as:

# btmgmt info
Index list with 1 item
hci0:	Primary controller
	addr 00:02:72:D3:79:8E version 3 manufacturer 10 class 0x040000
	supported settings: powered connectable fast-connectable discoverable bondable link-security br/edr debug-keys 
	current settings: powered bondable br/edr 
	name livingrune
	short name 

I tried playing on a B3 (choppy) and it looks like this:
https://pastebin.com/6Eg4uEG9
when playing the same song on the B2 (plays fine) it looks like this:
https://pastebin.com/asps3VcK

[borine]

Re rpi hci0/hci1 issue, a popular web search engine found this for me:
https://bugzilla.redhat.com/show_bug.cgi?id=1661961
Are you using kernel 4.19 by any chance? If so you could try upgrading to 4.20 or else blacklist the btsdio module - the link suggests that works for Fedora, so maybe it will for Arch also.
To blacklist the module, create a file called "/etc/modprobe.d/blacklist-btsdio.conf" with the following contents:
blacklist btsdio
then reboot.

[gearhead]

Thanks for the help! I searched on the wrong terms and didn't didn't find this. I am indeed on 4.19

# uname -r
4.19.32-1-ARCH

This solves the hci0/hci1 problem, but not the choppy playback. I did some btmgmt work and turned off some functionality on the BT radio and will see if it works any better tonight.

[borine]

Maybe Arch is using different firmware to Raspbian. For example, see the linked comment here:
raspberrypi/linux#1402 (comment)
It's probably worth checking to see if you have the files linked from there

[gearhead]

They are indeed different:
the latest one has this:

# Improved Bluetooth coexistence parameters from Cypress
btc_mode=1
btc_params8=0x4e20
btc_params1=0x7530

That mine does not have. I'll check it out and see if it works any better. I'll also have to look into this on Arch and find out why theirs is not updated.

[gearhead]

I did the update manually. No improvement. I am running kernel 4.19-32. If I disable the onboard bluetooth by stopping the brcm43438.service and put in a bluetooth dongle it all works as expected.

To get the onboard BT working on Arch, you need to run this service which runs this:
/usr/bin/btattach -B /dev/ttyAMA0 -P bcm -S 3000000
How does one enable it on raspian? Is this different?

[borine]

RPi on-board bluetooth is enabled out of the box with Raspbian.
I have no process btattach running, but I do have
/usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow - xx:xx:xx:xx:xx:xx
where the last parameter is the onboard bluetooth controller HCI address. This must have been started by the system, but I don't know how.
I know nothing about bluez implementation or configuration so have reached the limit of what I can contribute here.

[gearhead]

@borine You have contributed a lot to my understanding of this, thanks. My guess is that this is run at boot in some rc file under raspbian. I have not used raspian for a while, so I am not as familiar with it.
hciattach is the 'old way' of addressing the bt device. It is deprecated and no longer part of the default Bluez package. In Arch, you have to compile a special bluez-utils to get hciattach and the other hci tools. I assumed that the 'new way' was the 'right way'. I will try this tonight and see if it behaves any differently.

[gearhead]

So, I tried hciattach and now it works with wifi on, no stuttering.
My service file uses this:
ExecStart=/usr/bin/hciattach -n /dev/ttyAMA0 bcm43xx 921600 noflow -
I do not know what the significance of the 921600 and noflow are, but this worked. Will discuss this with the arch group

[borine]

Could you post a link to the Arch discussion here? If you have a working solution then it may be useful for others to follow - for example #193 looks like the same, or closely related, issue for a non-raspbian user.

[gearhead]

I am still struggling in the dark with a single match, here...
I posted to the Rpi group:
raspberrypi/linux#1402 (comment)
and to the maintainer of the pi-bluetooth AUR package here:
https://aur.archlinux.org/packages/pi-bluetooth/

It is a lot of wrangling to get these to work. As long as they have been around, there should be a cleaner way, IMO. AFAICT, Bluez has deprecated hciattach and replaced it with btmgmt and bluetoothctl. Lots of overlap between the 2 commands and some things can only be done in one or the other. I am unable to decipher much of what is going on other than copy and paste and try. The man page is not helpful to me nor is help.

On a B3+, I had to blacklist the btsdio module when using btattach to get the BT to show up on hci0 instead of hci1. When I use hciattach, that approach no longer works and my bluetooth device appears on hci1 and I cannot figure out how to put it on hci0, yet. Also, I figured out that I need to comment out the console setting in cmdline.txt. It was "console=ttyAMA0,115200" now it reads "console=" If I did not do this, it would disconnect as soon as I connected. I need to do more experimentation on this and figure out exactly what works and how/why. It was late last night and I was using a shotgun approach. It is a bit different (go figure) with the Zero, B3 and B3+. As of last night I was able to get it to work on the B3+(hci1) and B3 (hci0), but was failing with the Zero and went to bed. When I was able to get it working with hciattach it was smooth audio and wifi was enabled and running at the same time with no discernible effect on audio. That is encouraging. I just wish it were clear as to how and why it was happening.
I want someone to tell me how I get btattach to do the same thing as hciattach. It looks like hciattach actually reads the firmware in /etc/firmware/ whereas btattach does not. I made a new PKGBUILD file and built my own to do this in Arch. I hope to get to the bottom of this some day, but am not too hopeful. It is interesting that Raspbian uses the deprecated hciattach whereas the only way to get this in Arch is to build bluez-utils-compat AUR package..
PKGBUILD

# Maintainer: Ben Merritt <blm768@gmail.com>
# Contributor: Jesse Jaara <jesse.jaara: gmail.com>

pkgname=pi-bluetooth-rune
pkgver=1.2_3
pkgrel=1
pkgdesc="Services, firmware and udev rules to get integrated bluetooth running in Raspberry Pi 3"
arch=('armv6h' 'armv7h' 'aarch64')
url=""
license=('multiple')
depends=('bluez-utils-compat')
install=pi-bluetooth.install
_commitid=96eefffcccc725425fd83be5e0704a5c32b79e54
source=(
    https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/$_commitid/broadcom/BCM43430A1.hcd
    https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/$_commitid/broadcom/BCM4345C0.hcd
    https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/master/brcm/brcmfmac43430-sdio.txt
    https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/master/brcm/brcmfmac43455-sdio.txt
    LICENCE.broadcom_bcm43xx
    brcm43438.service
)
sha256sums=('8dd70b9003d39cb6175b4f3cd509666dad66ad23d3be1a68385817fb814c8930'
            'd09ce049f65619f007d604069d2b4d2a3ffe3cf897245287ef379955ce3969de'
            'fc3949a4c32f07c18308e7e145c7615be314158e7d714a80e04e4791f16495f9'
            'e971a57d928d2f2020906aca80a373565af5e4fa03357ed702a6bb5127df8b64'
            'e9223e5d6ca129789b08e8d24223fc3d28e8344911d93f2d6ab1b155970283d6'
            '5edfbc1fbd6fe23ab46600fc30156453abc17f80d9a69463ff18d19ad6d994e1')

package() {
  cd "${srcdir}"

  mkdir -p "${pkgdir}/usr/lib/firmware"
  mkdir -p "${pkgdir}/usr/share/licences"
  mkdir -p "${pkgdir}/usr/lib/systemd/system"
  mkdir -p "${pkgdir}/etc/firmware"

  cp BCM43430A1.hcd BCM4345C0.hcd "${pkgdir}/usr/lib/firmware/"
  cp brcmfmac43430-sdio.txt brcmfmac43455-sdio.txt "${pkgdir}/usr/lib/firmware/"
  cp LICENCE.broadcom_bcm43xx "${pkgdir}/usr/share/licences/"
  cp brcm43438.service "${pkgdir}/usr/lib/systemd/system/"
}
alarm@alarmpi:/mnt/alarm/RuneOS/packages/pi-bluetooth-rune$ cat PKGBUILD
# Maintainer: Ben Merritt <blm768@gmail.com>
# Contributor: Jesse Jaara <jesse.jaara: gmail.com>

pkgname=pi-bluetooth-rune
pkgver=1.2_3
pkgrel=1
pkgdesc="Services, firmware and udev rules to get integrated bluetooth running in Raspberry Pi 3"
arch=('armv6h' 'armv7h' 'aarch64')
url=""
license=('multiple')
depends=('bluez-utils-compat')
install=pi-bluetooth.install
_commitid=96eefffcccc725425fd83be5e0704a5c32b79e54
source=(
    https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/$_commitid/broadcom/BCM43430A1.hcd
    https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/$_commitid/broadcom/BCM4345C0.hcd
    https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/master/brcm/brcmfmac43430-sdio.txt
    https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/master/brcm/brcmfmac43455-sdio.txt
    LICENCE.broadcom_bcm43xx
    brcm43438.service
)
sha256sums=('8dd70b9003d39cb6175b4f3cd509666dad66ad23d3be1a68385817fb814c8930'
            'd09ce049f65619f007d604069d2b4d2a3ffe3cf897245287ef379955ce3969de'
            'fc3949a4c32f07c18308e7e145c7615be314158e7d714a80e04e4791f16495f9'
            'e971a57d928d2f2020906aca80a373565af5e4fa03357ed702a6bb5127df8b64'
            'e9223e5d6ca129789b08e8d24223fc3d28e8344911d93f2d6ab1b155970283d6'
            '5edfbc1fbd6fe23ab46600fc30156453abc17f80d9a69463ff18d19ad6d994e1')

package() {
  cd "${srcdir}"

  mkdir -p "${pkgdir}/usr/lib/firmware"
  mkdir -p "${pkgdir}/usr/share/licences"
  mkdir -p "${pkgdir}/usr/lib/systemd/system"
  mkdir -p "${pkgdir}/etc/firmware"

  cp BCM43430A1.hcd BCM4345C0.hcd "${pkgdir}/usr/lib/firmware/"
  cp brcmfmac43430-sdio.txt brcmfmac43455-sdio.txt "${pkgdir}/usr/lib/firmware/"
  cp LICENCE.broadcom_bcm43xx "${pkgdir}/usr/share/licences/"
  cp brcm43438.service "${pkgdir}/usr/lib/systemd/system/"
}

pi-bluetooth.install

post_install() {
  ln -s /usr/lib/firmware/BCM4345C0.hcd /etc/firmware/BCM4345C0.hcd
  ln -s /usr/lib/firmware/BCM43430A1.hcd /etc/firmware/BCM43430A1.hcd
  echo "Enable with: systemctl enable brcm43438.service"
}

The license file can be found in the pi-bluetooth arch AUR repository.

[GeoffreyFrogeye]

I can confirm having the same issue with a Pi 4B running Arch Linux ARM (32 bits), with btattach. Using hciattach fixes the issue, however I cannot say for sure that this is a btattach issue since the latter works for every bluetooth usage I tested besides bluez-alpha (I haven't tested pulseaudio's Bluetooth though).

---

I feel bad not adding much to the conversation, so I might as well give you how to get bluez-alpha working using Arch Linux ARM on a Raspberry Pi with the integrated BT module in a simpler way:

First, install pi-bluetooth and bluez-alsa-git. Then, as root, do:

mkdir /etc/firmware
ln -s /usr/lib/firmware/BCM4345C0.hcd /etc/firmware/BCM4345C0.hcd
ln -s /usr/lib/firmware/BCM43430A1.hcd /etc/firmware/BCM43430A1.hcd

systemctl enable brcm43438.service bluetooth.service bluealsa.service

Edit /boot/config.txt to make sure that there is no console output trashing the UART link with the bluetooth module:

console=

Create /etc/modprobe.d/blacklist-btsdio.conf with the content blacklist btsdio to remove the useless hci0 (might be optional?).

If you have a Raspberry Pi 4 or a 3B+ (maybe other models, sorry I don't know which are 921600 bauds and which are 3000000. If unsure, skip this and come back at it later if it didn't work), override the brcm43438 unit using systemctl edit brcm43438.service and typing in:

[Service]
ExecStart=
ExecStart=/usr/bin/hciattach -n /dev/ttyAMA0 bcm43xx 3000000 flow -

Then, reboot (to make sure the firmware gets written properly as it seems you can write it once per power cycle) and continue from here.

[gearhead]

Bluetooth can be used for so many different things and when someone on a forum says 'it works', you must understand that as 'it works for them on the things they have tried', nothing more. It seems that the effort that has gone into bluez was for devices and ethernet etc and audio seems to be a bit of an afterthought. btattach and hciattach do not result in the same performance with audio on my systems and btattach either doe snot work at all or is choppy. Personally, I'd like the bluez group to revisit btattach and resolve it there...

[macmpi]

Had similar choppy sound issue on Alpine, with btattach , whereas use of hciattach works fine.

It seems kernel needs some tweaked configs (CONFIG_SERIAL_DEV_BUS=m and CONFIG_BT_HCIUART_BCM=y) to get proper btattach support for bcm: hci_uart module built with Broadcom UART protocol support.
Have not had a chance to test that yet: anyone tested with such kernel?

[Mitschmaster]

i have arch linux kernel with CONFIG_SERIAL_DEV_BUS=y and CONFIG_BT_HCIUART_BCM=y but i have too very choppy sound with bluealsa.

[borine]

@Mitschmaster are you using a rpi? if so, which model? what is the hciattach or btattach command line ?

[Mitschmaster]

Im on a rpi 4 and i only tested the btattach command.
but i just found out: i created a device-tree overlay which gives me the hci but it behaves the same and sound is very choppy.
i did "btattach -B /dev/ttyAMA0 -P bcm -S 3000000 &" and tried various bitrates and flow control.
but as i said, because the device tree does the same, i think btattach is not the evil guy.

[Mitschmaster]

got another workaround:
brcm_patchram_plus --patchram /lib/firmware/brcm/BCM4345C0.hcd --baudrate 3000000 --enable_hci --use_baudrate_for_download --no2bytes --tosleep=1000000 /dev/ttyAMA0
also works.

[borine]

The most significant difference I can see between the source for hciattach and btattach is that hciattach calls a driver-specific init function (bcm43xx_init() for the RPi) which loads the firmware hcd file before any other uart config takes place; btattach does not call this function.

brcm_patchram_plus --patchram /lib/firmware/brcm/BCM4345C0.hcd --baudrate 3000000 --enable_hci --use_baudrate_for_download --no2bytes --tosleep=1000000 /dev/ttyAMA0
also works.

Do you mean that running that command before btattach results in goos sound, or that with that command btattach is not necessary, or what?

This RPi issue when not using Raspbian has been raised many times on this list, but I've never seen a definitive answer. Do you have a repeatable solution at last?

[Mitschmaster]

i mean that i ran brcm_patchram_plus instead of btattach. and had good sound, like i had with a bluetooth usb dongle.

[borine]

Ok, thanks; although unfortunately I still don't understand how this works. With neither hciattach nor btattach running, I don't see how the uart device is being configured. I haven't seen the source code to brcm_patchram_plus but my understanding is that it just uploads the firmware file. Maybe my understanding is wrong, or just outdated. Still, you have it working and that's very encouraging news.

[borine]

update - I've just found the source for brcm_patchram_plus and indeed it does set up the hci interface on the uart device if you pass the --enable_hci option. When I next get chance I'll see if this also works on Raspbian

[borine]

I can confirm that brcm_patchram_plus works also with Rasbian buster on a pi zeroW. You need to use firmware /lib/firmware/brcm/BCM43430A1.hcd but otherwise the command is the same. You also need to disable (and stop) the systemd hciuart.service that Rasbian uses to launch hciattach.

btattach on Raspbian buster also configures the uart hci correctly and uploads the firmware, but fails to set a usable bluetooth address. I get 00:00:00:00:00:00.

The interesting thing is that brcm_patchram_plus does not set the bt address unless explicilty told to do so on the command line. So perhaps btattach actually prevents the address from being set? I'll look into that next.

[borine]

another data point using btattach:

• using -P bcm I get the correct address but wrong baud rate (115200, not 3000000)
• using -P h4 I get a zero address but correct baud rate.

So the difference is somewhere in the protocol setup

[macmpi]

A safe way to get things setup is to reuse Pi Foundation's own btuart script & eventually customize it on particular distribution (ie replace $HCIATTACH /dev/serial1 by $HCIATTACH /dev/ttyAMA0)

Interestingly folks at LibreELEC recommend loading through compatible = "brcm,bcm43438-bt"; nodes in device-tree generally, but use same btuart script for Pi Setup, along with few patches for hciattach (including for bcm 3wire protocol)

[borine]

Interestingly folks at LibreELEC recommend loading through compatible = "brcm,bcm43438-bt"; nodes in device-tree generally

I'm not familiar with devicetree usage for bluetooth setup - is there a good general introduction anywhere I can read up on this? I notice that the LibreElec link you give relates to SDIO, is that relevant for bluetooth audio? (you can tell this is all beyond my experience level!)

but use same btuart script for Pi Setup, along with few patches for hciattach (including for bcm 3wire protocol)

Just to add to that: the patches you mention are from the Pi Foundation's build of hciattach, and are specifically to add support for the original Pi3 and the PiZeroW onboard bluetooth, they are not necessary for the Pi3B+ or Pi4.

[borine]

@macmpi wrote:

Have not had a chance to test that yet: anyone tested with such kernel?

Yes - in fact the Raspbian kernel is now built that way. The problem is that when bluez re-factored the vendor-specific functions from user-space tools to kernel modules (ie when hciattach was deprecated in favour of btattach), the they were split between the hci config (in module hci_uart) and the bluetooth config (in module btbcm). Unfortunately, the bcm43xx requires the host to explicitly select a baudrate for the uart, otherwise it defaults to 115200, and this step of the config was lost during the refactoring.

Once the bcm43xx firmware is uploaded, the controller baud rate reverts to 115200, so the host has to then set it to 3000000 (or whatever the application has requested). The btbcm driver does not do this, and in fact I can see no way in the API for user space to communicate its chosen baud rate. So when using btattach the hci is set up to use 115200 baud which is insufficient to maintain a steady A2DP audio stream.

My conclusion is that at the present time btattach cannot be used successfully with bcm4xx over a uart hci.

I don't know enough about device tree overlays to say whether one could be used to pre-configure the operating baud rate of the bcm43xx. That would be a neat fix for boards such as the Pi. Failing that, it is left to user space to implement the necessary vendor-specifc HCI command and tty config to change the baud rate after initial setup - so perhaps a patch to the btattach application code.

[damaev]

Hi everybody,

I really spend a lot of time trying to figure out the reason for my stuttering audio (with wifi off) while a working solution for my issue has already been released years ago: reducing the baudrate to 460800. (I was always thinking about increasing it...) See original post here: raspberrypi/linux#2264 (comment)

What to do:
edit /usr/bin/btuart (loaded during boot by hciuart.service)
reduce the baud rate from 921600 to 460800 (in the only possible line)

@borine btattach didn't work for me either. So I kept htattach in /usr/bin/btuart

Following additional information:

The rev 1.2 Pi3B lacks the flow control signals to the Bluetooth modem (we ran out of pins), but the rev 1.3 board drops the BT PCM interface and hooks up the flow control. I think what you are seeing is occasional data loss when the FIFOs overflow, something which is hard to avoid in all circumstances. You may be able to lessen the problem by reducing the baudrate on the modem - try editing /usr/bin/btuart, replacing the 921600 with 460800 and rebooting."

It seems the 3B+ has the same problem described here for the first revisions of the 3B.

Originally posted by @docgloucester in nicokaiser/rpi-audio-receiver#38 (comment)

[Mitschmaster]

hi.
setting lower baud rate did not solve the issue for me.

[borine]

@Mitschmaster

setting lower baud rate did not solve the issue for me

do you mean the issue when using btattach? if so, then that is to be expected.. As I tried to explain in comment #205 (comment) this is a bug/design limitation of the btbcm kernel module which does not set the desired baud rate after loading the firmware. The only workaround I know is to use a tool that does not require support from the kernel - so basically hciattach or brcm_patchram_plus.

You can check the baudrate of the UART with
sudo stty -F /dev/ttyAMA0 speed

If it reports 115200 (the default setting of the bcm43xx chip) then that is too low for a2dp

[macmpi]

FWIW hciattach/btuart are no longer needed with firmware post 5.4.50 from Pi Foundation releases.
BT firmware can be automatically loaded at boot by device tree by setting dtparam=krnbt=on in config.txt: serial interface is set at max speed with HW flowcontrol.

( note, on Pi3b rev1.2 boards, one may want to limit baudrate as previously with dtparam=krnbt_baudrate=<rate here> as those boards do not have HW flowcontrol. This limitation may go away if/when H5 protocol is implemented in BCM43340 driver)

[gearhead]

Building 5.4.50 now. We will see how well it works. RPi foundation took 4 years to release this. I hope it works.

Tried it last night and got no joy. I'll have to read up on it a bit more. As it is, I still have to have brcm43438.service running and bluetooth.service before bluetoothctl acknowledges that there is a Bt module onboard. If I disable brcm43438 then reboot, no bt module shows up.

[macmpi]

@gearhead did you try with Foundation's firmware files.
Since you built kernel on your side, did you take care about changes in defconfigs in particular?

CONFIG_SERIAL_DEV_BUS=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y

[onny]

FWIW hciattach/btuart are no longer needed with firmware post 5.4.50 from Pi Foundation releases.
BT firmware can be automatically loaded at boot by device tree by setting dtparam=krnbt=on in config.txt: serial interface is set at max speed with HW flowcontrol.

( note, on Pi3b rev1.2 boards, one may want to limit baudrate as previously with dtparam=krnbt_baudrate=<rate here> as those boards do not have HW flowcontrol. This limitation may go away if/when H5 protocol is implemented in BCM43340 driver)

Thank you so much! This is working fine now on ArchLinuxARM and my Raspberry PI 4. Bluetooth audio is playing fine and now special tweaks are needed anymore.
I documented my setup here https://git.project-insanity.org/onny/py-piradio#bluetooth-audio-playback-related-configurations
I only had to install firmware files:

pacman -S firmware-brcm43xx

and add

[...]
dtparam=krnbt=on

to /boot/config.txt. Now everything is working fine 👍
Thanks for the info!

[macmpi]

@onny glad it helped: you may want to spread the word onto ArchLinuxARM pi-bluetooth package discussion and related Pi wiki

[gearhead]

OK. I got this to work on a B3 running armv7. The package firmware-brcm43xx is not available for armv6 (PiZeroW) nor for aarch64 (Pi2-4). I'll dig into it and see what is up and if I can build a package for those 2 architectures and see if it works.

Does anyone know if there are specific kernel build flags that are needed to make this work? I am re-building the aarch64 kernel and will see if it 'just works', but I already rebuilt 5.4.50-1 with my config and on aarch64 it does not work with the config.txt setting. I built the firmware-brcm43xx and installed it for aarch64 and it installed without any errors. Still no BT joy on aarch64.

[gearhead]

got it working on aarch64. no choppy sound

[etienne-85]

hi! @gearhead Do you have any update regarding PiZeroW?
I'm trying to get bluetooth work on archlinux but no luck yet :(

[gearhead]

Works for me on zero, b2 b3 and b3+

…

On Sat, Sep 26, 2020, 17:36 etienne1911 ***@***.***> wrote: hi! @gearhead <https://github.com/gearhead> Do you have any update regarding PiZeroW? I'm trying to get bluetooth work on archlinux but no luck yet :( — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#205 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAARWJGOUYJ2SCH4DGG4CATSHZUIPANCNFSM4HDYNKGA> .

[etienne-85]

Ok that's good news. is there any additional firmware to install like 'firmware-brcm43xx' because I coudn't find any for armv6.
To lauch bluetooth service; I have to manually loaded btusb with modprobe but I don't kwow if I should do this? due to lack of information I'm a bit lost between official and archarm wikis... I guess we are no longer supposed to install pi-bluetooth anymore?
Currently I can launch bluetoothctl, but I can't see nor set any default controller. I guess I didn't did things properly and I saw some issues when bluetooth service launch. If you have any hint to help me?

[borine]

Latest raspberry pi firmware appears to be working well together with latest bluez-alsa code (ie not the bluealsa package in the RaspiOS repository which is currently very outdated and somewhat broken).

If you have a specific issue with the latest bluez-alsa on RPi please open a new issue as much of the information here is now out of date.