md
A Note on BlueAlsa 0.9 with BlueZ 5.49 and 5.50 on Rasbian Stretch
January 28, 2019
<-A Note on BlueAlsa 0.9 with BlueZ 5.43 on Rasbian Stretch --
<-Bluetooth Audio with Rasbian Stretch on the Raspberry Pi 3

This is a continuation of the previous note on Bluetooth on the November 2018 version of Raspbian Stretch in which the default version of BlueZ is replaced with version 5.49 and later version 5.50. It will be shown that for streaming audio, there is not much difference between these three versions of Bluetooth protocol stack for Linux.

Table of Contents

  1. Installing BlueZ 5.49 on Raspbian Stretch
  2. Installing BlueZ 5.50 on Raspbian Stretch
  3. Conclusion

Installing BlueZ 5.49 on Raspbian Stretch toc

In the last note, I showed how to work around three of the four errors occurring when starting the bluetooth.service. I undid those changes, reverting back to the original /lib/systemd/system/bluetooth.service and removing the cron entry to restart the service on boots. After a reboot, the initial service status with its multiple errors returned.

pi@tarte:~ $ sudo systemctl status bluetoo* ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-01-28 12:54:28 AST; 2min 52s ago Docs: man:bluetoothd(8) Main PID: 423 (bluetoothd) Status: "Running" CGroup: /system.slice/bluetooth.service └─423 /usr/lib/bluetooth/bluetoothd Jan 28 12:54:27 tarte bluetoothd[423]: Bluetooth daemon 5.43 Jan 28 12:54:28 tarte systemd[1]: Started Bluetooth service. Jan 28 12:54:28 tarte bluetoothd[423]: Starting SDP server Jan 28 12:54:28 tarte bluetoothd[423]: Bluetooth management interface 1.14 initialized Jan 28 12:54:28 tarte bluetoothd[423]: Failed to obtain handles for "Service Changed" characteristic Jan 28 12:54:28 tarte bluetoothd[423]: Sap driver initialization failed. Jan 28 12:54:28 tarte bluetoothd[423]: sap-server: Operation not permitted (1) Jan 28 12:54:28 tarte bluetoothd[423]: Failed to set privacy: Rejected (0x0b) Jan 28 12:54:28 tarte bluetoothd[423]: Endpoint registered: sender=:1.6 path=/A2DP/SBC/Source/1 Jan 28 12:54:28 tarte bluetoothd[423]: Endpoint registered: sender=:1.6 path=/A2DP/SBC/Sink/1 ● bluetooth.target - Bluetooth Loaded: loaded (/lib/systemd/system/bluetooth.target; static; vendor preset: enabled) Active: active since Mon 2019-01-28 12:54:28 AST; 2min 52s ago Docs: man:systemd.special(7) Jan 28 12:54:28 tarte systemd[1]: Reached target Bluetooth.

Essentially, I followed my own instructions to update to BlueZ 5.49 as found in 2. Updating BlueZ changing a couple of minor things. For one I kept a copy of the original configuration file /etc/dbus-1/system.d/bluetooth.conf. This makes for a simpler adjustment later. Secondly, I cleaned up as I went along.

pi@tarte:~ $ sudo cp /etc/dbus-1/system.d/bluetooth.conf /etc/dbus-1/system.d/bluetooth_conf.543 pi@tarte:~ $ sudo apt install -y libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev ... pi@tarte:~ $ wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.49.tar.xz ... pi@tarte:~ $ tar -xf bluez-5.49.tar.xz pi@tarte:~ $ mkdir downloads pi@tarte:~ $ mv bluez-5.49.tar.xz downloads pi@tarte:~ $ cd bluez-5.49/ pi@tarte:~/bluez-5.49 $ ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var --enable-experimental ... pi@tarte:~/bluez-5.49 $ make -j4 ... pi@tarte:~/bluez-5.49 $ sudo make install ... pi@tarte:~/bluez-5.49 $ cd - /home/pi pi@tarte:~ $ rm -r bluez-5.49/ pi@tarte:~ $ sudo adduser pi bluetooth

Strictly speaking that last line was not needed in my case because the default user had already been added to the bluetooth group. But do make sure pi (or whatever is the name of the user) is a member of the group, otherwise nothing can be accomplished.

pi@tarte:~ $ groups pi adm dialout cdrom sudo audio video plugdev games users input netdev bluetooth gpio i2c spi

Comparing the freshly installed configuration file with the old one, only one more "hole" was punched: LE Advertisement, whereas the three "watchers" (Thermometer, Heart Rate and Cycling Speed) had been disabled. I am not sure if these changes are at all meaning full. However the missing bluetooth group policy in the new configuration file is needed. Accordingly I edited the old configuration file to add one line and saved it as the current configuration file.

pi@tarte:~ $ cd /etc/dbus-1/system.d pi@tarte:/etc/dbus-1/system.d $ sudo nano bluetooth_conf.543

Add the line as shown below.

<allow send_interface="org.bluez.GattCharacteristic1"/> <allow send_interface="org.bluez.GattDescriptor1"/> <allow send_interface="org.bluez.LEAdvertisement1"/> <allow send_interface="org.freedesktop.DBus.ObjectManager"/> <allow send_interface="org.freedesktop.DBus.Properties"/> </policy>

And save the file as bluetooth.conf. Reboot the system to see how things have changed.

pi@tarte:/etc/dbus-1/system.d $ sudo reboot Connection to tarte.local closed by remote host. Connection to tarte.local closed. michel@hp:~$ ssh pi@tarte.local ... pi@tarte:~ $ sudo systemctl status bluetooth.service ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-01-28 13:34:46 AST; 1min 37s ago Docs: man:bluetoothd(8) Main PID: 532 (bluetoothd) Status: "Running" CGroup: /system.slice/bluetooth.service └─532 /usr/libexec/bluetooth/bluetoothd Jan 28 13:34:46 tarte systemd[1]: Starting Bluetooth service... Jan 28 13:34:46 tarte bluetoothd[532]: Bluetooth daemon 5.49 Jan 28 13:34:46 tarte systemd[1]: Started Bluetooth service. Jan 28 13:34:46 tarte bluetoothd[532]: Starting SDP server Jan 28 13:34:46 tarte bluetoothd[532]: Bluetooth management interface 1.14 initialized Jan 28 13:34:46 tarte bluetoothd[532]: Failed to set privacy: Rejected (0x0b) Jan 28 13:34:46 tarte bluetoothd[532]: Endpoint registered: sender=:1.6 path=/A2DP/SBC/Source/1 Jan 28 13:34:46 tarte bluetoothd[532]: Endpoint registered: sender=:1.6 path=/A2DP/SBC/Sink/1

There remains that pesky failure which disappears when the service is restarted.

pi@tarte:~ $ sudo systemctl restart bluetooth.service pi@tarte:~ $ sudo systemctl status bluetooth.service ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-01-28 13:38:33 AST; 6s ago Docs: man:bluetoothd(8) Main PID: 705 (bluetoothd) Status: "Running" CGroup: /system.slice/bluetooth.service └─705 /usr/libexec/bluetooth/bluetoothd Jan 28 13:38:33 tarte systemd[1]: Starting Bluetooth service... Jan 28 13:38:33 tarte bluetoothd[705]: Bluetooth daemon 5.49 Jan 28 13:38:33 tarte systemd[1]: Started Bluetooth service. Jan 28 13:38:33 tarte bluetoothd[705]: Starting SDP server Jan 28 13:38:33 tarte bluetoothd[705]: Bluetooth management interface 1.14 initialized Jan 28 13:38:33 tarte bluetoothd[705]: Endpoint registered: sender=:1.23 path=/A2DP/SBC/Source/1 Jan 28 13:38:33 tarte bluetoothd[705]: Endpoint registered: sender=:1.23 path=/A2DP/SBC/Sink/1

So back to the brute force solution, this time adding a comment to remember why that entry is added.

pi@tarte:~ $ crontab -e
# m h dom mon dow command # work around bluetoothd: Failed to set privacy: Rejected (0x0b) @reboot sleep 5 && sudo systemctl restart bluetooth.service

Verification of its status after a reboot shows that the service started, or more accurately, restarted without a problem.

pi@tarte:~ $ sudo reboot Connection to tarte.local closed by remote host. Connection to tarte.local closed. michel@hp:~$ ssh pi@tarte.local ... pi@tarte:~ $ sudo systemctl status bluetooth.service ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-01-28 14:08:37 AST; 59s ago Docs: man:bluetoothd(8) Main PID: 559 (bluetoothd) Status: "Running" CGroup: /system.slice/bluetooth.service └─559 /usr/libexec/bluetooth/bluetoothd Jan 28 14:08:37 tarte systemd[1]: Starting Bluetooth service... Jan 28 14:08:37 tarte bluetoothd[559]: Bluetooth daemon 5.49 Jan 28 14:08:37 tarte systemd[1]: Started Bluetooth service. Jan 28 14:08:37 tarte bluetoothd[559]: Starting SDP server Jan 28 14:08:37 tarte bluetoothd[559]: Bluetooth management interface 1.14 initialized Jan 28 14:08:38 tarte bluetoothd[559]: Endpoint registered: sender=:1.9 path=/A2DP/SBC/Source/1 Jan 28 14:08:38 tarte bluetoothd[559]: Endpoint registered: sender=:1.9 path=/A2DP/SBC/Sink/1

There was a change in the content of the service configuration file.

pi@tarte:~ $ cat /lib/systemd/system/bluetooth.service [Unit] Description=Bluetooth service Documentation=man:bluetoothd(8) ConditionPathIsDirectory=/sys/class/bluetooth [Service] Type=dbus BusName=org.bluez ExecStart=/usr/libexec/bluetooth/bluetoothd NotifyAccess=main #WatchdogSec=10 #Restart=on-failure CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE LimitNPROC=1 ProtectHome=true ProtectSystem=full [Install] WantedBy=bluetooth.target Alias=dbus-org.bluez.service

Verion 5.49 of the daemon is installed in /usr/libexec/bluetooth while the old version remains in /usr/lib/bluetooth. I removed the old directory hoping that not having done that before did not have an impact.

pi@tarte:~ $ sudo rm -r /usr/lib/bluetooth

Testing showed that the Raspberry Pi could both send out an audio stream over a Bluetooth connection (i.e. source a stream) and receive an audio stream (i.e. sink a stream). Do not forget that the BlueAlsa configuration had to be modified to allow the sinking of Bluetooth streams, as explained in the previous notes.

Installing BlueZ 5.50 on Raspbian Stretch toc

To test version 5.50 of BlueZ, which is currently the newest version, I started with a fresh install of Rasbpian Stretch. The installation of version 5.50 is almost exactly the same as above with version 5.49.

pi@berry:~ $ sudo rm -r /usr/lib/bluetooth pi@berry:~ $ sudo cp /etc/dbus-1/system.d/bluetooth.conf /etc/dbus-1/system.d/bluetooth_conf.543 pi@berry:~ $ sudo apt install -y libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev ... pi@berry:~ $ wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.50.tar.xz ... pi@berry:~ $ tar -xf bluez-5.50.tar.xz pi@berry:~ $ mkdir downloads pi@berry:~ $ mv bluez-5.50.tar.xz downloads pi@berry:~ $ cd bluez-5.50/ pi@berry:~/bluez-5.50 $ ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var --enable-experimental ... pi@berry:~/bluez-5.50 $ make -j4 ... pi@berry:~/bluez-5.50 $ sudo make install ... pi@berry:~/bluez-5.50 $ cd - /home/pi pi@berry:~ $ rm -r bluez-5.50/ pi@berry:~ $ sudo adduser pi bluetooth Adding user `pi' to group `bluetooth' ... Adding user pi to group bluetooth Done. pi@berry:~ $ sudo apt install bluealsa -y ... Setting up bluealsa (0.9) ... bluealsa.service is a disabled or a static unit, not starting it. pi@berry:~ $ sudo systemctl start bluealsa pi@berry:~ $ sudo reboot Connection to berry.local closed by remote host. Connection to berry.local closed. michel@hp:~$ ssh pi@berry.local ... pi@berry:~ $ sudo systemctl status bluetooth.service ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-01-28 18:29:07 AST; 1min 39s ago ... Jan 28 18:29:07 berry bluetoothd[417]: Failed to set privacy: Rejected (0x0b)

This is exactly where we were with version 5.49. And I have no better solution than to restart the service after each reboot to get rid of the error message.

Interestingly, it was possible to source and sink an audio stream over a Bluetooth connections even without rebooting the system to get rid of that error. Do not forget that the BlueAlsa configuration had to be modified to allow the sinking of Bluetooth streams, as explained in the previous notes.

Conclusion toc

I only tried out the new versions of BlueZ and BlueALSA because of a message from a reader about the new error: Failed to set privacy: Rejected (0x0b). I can now answer his question with some consequence. That failure is of no consequence when it comes to streaming sound to a Bluetooth speaker or when using the Raspberry Pi to read a sound stream from a Bluetooth device. Indeed as these last two notes have shown, it is not even necessary to update BlueZ for those purposes.

To be sure, there are changes but they do not seem to be directly related to BlueZ. I believe them related to the new version of BlueAlsa included in the November 2018 edition of Raspbian. Perhaps changes to one or both of two other packages, bluez-firmware and pi-bluetooth, could also be at play.

The comments quoted in the previous note with respect to BLE connections reveal that there is a real problem, but I have not encountered it. Indeed, I have not used Bluetooth on the Raspberry Pi since my initial tests back in the spring of last year. Hence, I do not know if the simple brute force restarting of the Bluetooth service on reboots is a viable solution. It is certainly not very elegant.

<-A Note on BlueAlsa 0.9 with BlueZ 5.43 on Rasbian Stretch --
<-Bluetooth Audio with Rasbian Stretch on the Raspberry Pi 3