There were no cheap micro SD cards in a nearby big box store specializing in everything for the office, but there was a small pile of inexpensive Bluetooth speakers in the clearance bin. Bluetooth devices are something I know very little about except for a brief use of a cheap keyboard which I threw away when the V key disappeared rather quickly. The speaker packaging talked of the "premium aluminum (or aluminium if you prefer) body", the "33 ft wireless range" (33 is an odd number, corresponds to 10 metres I suppose), the "3 hours of playtime" (not likely!). But most intriguing was the "built in microphone for call answering". Could I transform it into something like the Amazon Dot or the Google Home mini when used in combination with a Raspberry Pi 3 which has built in Bluetooth? The price was right for experimentation: $10 CDN + $1.50 recycling fee + 15% sales tax.

Testing with an Android tablet confirmed that the speaker could stream audio and that the microphone could be used, although the quality was definitely inferior to that of the tablet. And it turned out that the microphone could only be accessed using an application found on Play Store.

The device, named AUDIO POD was sold under the XTREME SOUND label, but I have since realised that there are many variation on the theme sold under various labels. It also turns out that for the same price I could have obtained an upgraded model from the typical Chinese seller... oh well.

Before going ahead with the grand scheme, I had to learn the basics of using Bluetooth with a Raspberry Pi 3. Here is a description of my first steps in this arcane world.

Table of Content

1. Starting All Over... Again
2. Bluetooth on Raspbian Stretch
3. Connecting Bluetooth Devices
4. Connecting Bluetooth Devices with PIN Code
5. Playing Sound Through a Bluetooth Speaker
6. Controling the Playback Volume of a Bluetooth Speaker
7. Using Multiple Speakers
8. Caveat (added May 12, 2018)

Starting All Over... Again

This first section is about setting up Raspbian (stretch) on a Raspberry Pi 3 (RPi3 for short) for headless operation. It can probably be skipped by most users of the RPi3. It is a bit terse and assumes you know how to locate a newly connected computer on the local area network. This should work with any Raspberry Pi.

When this was initially written, the most recent Rasbpian image available from the Raspberry Foundation was

Raspbian Stretch Lite
	Minimal image based on Debian Stretch
	Version: November 2017
	Release date: 2017-11-29
	Kernel version: 4.9.

Raspbian Stretch Lite
	Minimal image based on Debian Stretch
	Version: April 2018
	Release date: 2018-04-19
	Kernel version: 4.14.

I downloaded that image and burned it to a 8GB SD card using Etcher as per the instructions at raspberrypi.org. I suggest that before doing this you uncheck the Auto-unmount on success option in the programs Settings. If this is not done, it will be necessary to remove and reinsert the SD card in the desktop SD card reader to perform the next step.

In order to configure the RPi3 without monitor and keyboard, I created an empty file called ssh in the card's boot partition.

Then I unmounted the two partitions on the SD card, inserted the latter in the RPi3 SD card reader, connected an Ethernet cable to the board and powered it up. If all goes well, the red and green LED will flash on and off. I think the RPi3 is expanding its file system so give it some time to perform that one time task. Wait until the green LED no longer flashes and the red LED is mostly on. It is time to open an SSH session. Use the usual means to find the IP address of the RPi3. In my case, it was simple, because I had recently connected the RPi3 to the network, so its IP address lease was still in effect. However this meant that the security key had to be changed. Its no big deal, just follow the instructions if that happens.

We are in! First thing first, I used raspi-config to change the configuration to suit my situation. The most important changes at this time are setting the password and enabling SSH.

1. Change password for the current user mandatory
2. Configure network settings
   • N1 Hostname on the network to rpi3
   • N2 Provide Wi-fi credentials (network name and password)
3. Boot Options - did nothing
4. Localisation Options
   • I1 Change Locale to add fr_CA
   • I2 Change Timezone - to America/Moncton
5. Interfacing Options
• P2 SSH - enabled mandatory
• P5 I2C - enabled
6. Overclock - did nothing
7. Advanced Options
• A3 Memory Split - minimum 16 MB for the GPU

I rebooted as asked and then updated and upgrade the system.

That was something new... a few days ago, there was no update to raspi-config. Hope that having used it before the update will not have an impact.

Bluetooth on Raspbian Stretch

The RaspberryPi.org documentation about Bluetooth in its new Raspbian image (stretch) mentions a change of approach.

I take this to mean that older posts about Bluetooth and PulseAudio may not be that useful. Looking at the boot log for Bluetooth related entries, the situation looks good.

That reminded me that the UART is connected to the Bluetooth chip on the Raspberry Pi 3.

Apparently this is not as bad as it looks. The SIM Access Profile (SAP) would have allowed the RPi3 to access a SIM card of a Bluetooth enabled phone. This is far from something of interest to me at this point. In a lengthy exchange on the Rasbperry Pi forum, entitled Raspbian Stretch Bluetooth is Broken there is a way to get rid of the error message by stopping the attempt to load the SAP server: add the --noplugin=sap option when starting the Bluetooth deamon. Since I am paranoid I made a back up of the of bluetooth.service file before doing that.

As explained in an exchange on Bluetooth does not work with Raspbian Stretch and Raspberry Pi 3 there is also a problem of permissions. The user (pi) needs to be a member of the bluetooth group to have access to the service over DBus.

I then rebooted and, as expected, the two SAP related errors have disappeared. However the Failed to obtain handles for "Service Changed" characteristic is still there. On the other hand things it was possible to "pair" with the Bluetooth speaker. I turned the speaker on and waited until I heard "Bluetooth mote" (or "moat"; that is what I hear, instead of the expected "mode") and then started the interactive utility bluetoothctl to connect.

This is definitely an improvement, but the connection did fail. Incidentally, the agent invoked is the module that performs the pairing with the device. As for the Universally Unique IDentifiers, (UUIDs), they correspond to capabilities of the speaker. More on that in a latter post.

Further reading of the forum exchange gave another piece of the solution. Load a bit of software: the blueALSA proxy. I checked, it was indeed missing so I installed it.

This will load the service immediately, there is no need to restart anything except for bluetoothctl to try to connect once again. It turned out the speaker was still paired, so all I had to do was to connect to it.

The speaker made a ding dong type of noise to indicate that it was connected. This is progress. Note that it was not necessary to register an agent since the speaker had already been paired. Time to move on to the problem of reconnecting the speaker without going through this pairing rigamarole.

Connecting Bluetooth Devices

Thankfully, it is not necessary to go through the interactive procedure described above to connect a Bluetooth device, once it has been paired. If a paired device is "trusted" by a controller, such as the Raspberry Pi 3, then connection will be done automatically whenever the device is near a controller that trusts it.

As far as I known, a device such as a speaker can be connected to only one controller at a time. That was something to remember as I connected the Bluetooth speakers with both my desktop computer and the RPi3 nearby. I had to make sure that I disabled the Bluetooth adapter on the desktop when connecting the speaker to the RPi3.

Trusting a paired device is a simple procedure.

To test, I rebooted the RPi3 and turned off the speaker at the same time. Once the Raspberry Pi completed its boot routine, I turned on the speaker and was pleased to hear it make its ding dong connected noise after a few seconds.

For the sheer pleasure of it, I used the D-Bus introspection tool busctl to monitor the status of the speaker as I turned it off and then back on again.

It does appear that it is necessary to power cycle the speaker when the RPi3 is rebooted. Here is what we have after rebooting and turning the speaker on and off.

If automatic connection is not desired, then "untrust" the device.

The speaker remained paired, and it is possible to connect to it with a single command.

Disconnecting is just as simple.

If quieter commands are required, send the output and the standard error file to null.

Then you can rely on the sound emanating from the speaker for a confirmation.

Finally to "unpair" a device, that is to remove its MAC address from the controller's database of paired devices use the remove <device_mac> command (of course <device_mac> is replaced with the device MAC address such as 30:21:3E:31:C6:2B) in bluetoothctl. Should you want to connect the device in the future, it will have to be paired again.

Connecting Bluetooth Devices with PIN Code

Most Bluetooth keyboards and perhaps other Bluetooth devices have a slightly more complicated pairing procedure. There is an extra step, an exchange of a PIN number.

To try this out, I borrowed the Adesso keyboard that my spouse sometime uses with her IPad. I turned the keyboard on, and then pressed the Bluetooth pairing button. On this particular keyboard, it is marked <«.»> in the centre above the keys. A Bluetooth LED then starts to flash signaling the start of the discovery phase. It is time to pair and connect.

The PIN code changes at each pairing. There is no simple way to test that the keyboard works without connecting a monitor to the RPi. I am too lazy to do that, but I trust it would have worked.

If the Raspberry Pi ends up in the living room and if the keyboard does not work with the IPad because it connected with the RPi there will be two consequences. First it will take a long time to figure out what is going on. Second there will be hell to pay. I thought it best to remove the keyboard from the list of paired devices.

Playing Sound Through a Bluetooth Speaker

Now its time to try to make a sound come out of the speaker. Luckily, a recent discussion on the Raspberry forum entitled Bluetooth audio on stretch can get us there. At this point a WAV (signed 16 or 32 bit PCM encoded) file is needed on the RPi3. I used Audacity to export a MP3 piece of music to both 16 and 32 bit formats. And the Bluetooth speaker must be connected.

That worked. There is only one Bluetooth device on the Raspberry Pi 3 as can be seen from the hciconfig command.

So we can simplify the command a little bit by not indicating which Bluetooth device to use. Similarly, the a2dp profile seems to be the default and does not need to be specified.

Instead of identifying the playback device in detail in the aplay command, a default configuration file, can be created. It would be better to save an already existing /home/pi/.asoundrc file before overwriting it.

The filename is all that will need to be specified to play it.

If there was a previously existing .asoundrc configuration file, and if it was sound (pun intended), then it would be best to combine it with the new one. There is an example of a configuration file with three output devices in section 7 below.

Controling the Playback Volume of a Bluetooth Speaker

The music is played at full volume, which can be loud by my standards, but would be merely a whisper for others. It is possible to control the volume, as the music is played, by using AlsaMixer in a second terminal.

Press on F3 to view the Playback devices. Use the left and right cursor keys to select the AUDIOPOD2 - A2DP device. Then use the up and down cursor keys to adjust the volume of the output as the WAV file is played in another terminal as explained in the previous section.

Alternatively, the volume can be set before playing the music with the command line.

Append a "+" or "-" to move the volume up or down. For example to set the volume to 30% of full volume when it is already at 50%, request a diminution of 20% as follows.

Thus 20%- is not a reduction of 20% of the current volume because that would have brought the volume to 40% of the maximum (20% of 50% is 10% and 50% - 10% give 40%.

Using Multiple Speakers

I used the raspi-config utility to enable the analogue output through the 3.5 mm jack. I then connected a typical pair of powered computer speakers to the RPi3. And while at it, I added a second Bluetooth speaker which is just as easy as adding the first. Pair it and connect to it with bluetoothctl.

Modify the sound configuration file

Now a sound file can be played through the built in 3.5mm analogue output.

To hear the sound through one of the Bluetooth speakers, which of course needs to be connected, use the command.

It remains possible to set the volume. In alsamixer both speaker will be visible. On the command line, the name of the device is now different.

But what about playing the same sound file through both speakers simultaneously? I tried following advice from Eliot Eshelman without success. I keep on getting xrun errors - which means buffer overruns or underruns.

For the fun of it, I tried playing different wav files simultaneously from different terminals. There is no problem in running the analogue audio and one of the Bluetooth speaker at the same time. But running both Bluetooth speakers does not work at all well, there is a lot of stuttering.

Caveat

When I tried to run Music On Console (MOC) on the Raspberry Pi using Bluetooth speakers, I ran into difficulties. It turns out that the culprit was the .asoundrc configuration file.

The solution that I found (see Music on Console, ALSA, and Bluetooth on Raspbian Stretch) was to use a bare bones configuration file:

Then aplay, alsamixer and amixer work with the Bluetooth speaker if the -D bluealsa option is included in the command line. When no device is specified, the sound is output to the 3.5 mm jack (or HDMI connector).

That "solution" will not be very useful if different Bluetooth speakers will be connected at different times. For those that find themselves in that situation, I suggest looking at the script memeplex presented at the end of the Unable to find definition 'defaults.bluealsa.interface' issue that he raised on the bluez-alsa github site. My reading of the script is that it creates a new .asoundrc configuration file on the run, setting the bluealsa.device value (the Bluetooth speaker MAC address) from bluetoothctl.