No, not a Bluetooth related post again! Rather surprisingly, the old posts about Bluetooth on the Raspberry Pi still generate a fair amount of traffic on this site. Not too long ago there was a query on that topic but in relation to the Orange Pi Zero Plus 2. I could not provide a definitive answer as I do not have that board. On the other hand, I do have an Orange Pi PC 2 (OPiPC2 for short) which shares the same Allwinner H5 SOC. Unlike the Zero, the PC 2 does not have built-in wireless connectivity. However, an old Wi-Fi-USB dongle and the cheapest Bluetooth-USB dongle found from the traditional Chinese sellers were recognized by the system. That was close enough to investigate Bluetooth on an H5 Orange Pi running the latest version of Armbian Bionic (kernel version 5.4.14). Of course, what is reported below may not apply to a Zero Plus 2 which relies on an AP612 chip for Wi-Fi and Bluetooth.

Table of Contents

1. Sound ALSA
   1. Playing Sound
   2. Recording Sound
2. Bluetooth
   1. Compiling BlueALSA
   2. Sending an Audio Stream to Bluetooth Speakers
   3. Playing an Audio Stream from a Bluetooth Device
   4. BlueALSA systemd Service File
3. References

Sound - ALSA

As before, I want to stream audio using Bluetooth as a transport mechanism. The obvious first step is to make sure that audio works on the OPiPC2. In other words, the OPiPC2 must have audio capabilities, functionning sound card device drivers must be installed and ALSA (Advanced Linux Sound Architecture) which provides an application programming interface for the sound cards must be running. ALSA is part of the Linux kernel and all the rest is in place at least with the latest version of Armbian Bionic.

Playing Sound

I connected a powered pair of speakers to the 3.5 mm jack, enabled the analogue output and tested it following the SUNXI Audio Codec instructions. That means first creating a system wide ALSA configuration file asound.conf in the /etc/ directory. The nano editor is fine for this, but any text editor such as vim could be used.

Here is the content added to the file.

Again, this is explained in the SUNXI Wiki as well as the next step on testing that the audio output is directed to the 3.5 mm jack.

It's hard to show sound on a Web page, but take my word for it, "Front Left Front Right" was repeated four times. The speaker-test options used are:

• -twav: test using a WAV file ("Front Left, "Front Right" ...).
• -c2: test 2 channels (front left and right speakers)
• -l4: repeat the test 4 times (loop count)

If the sound is not heard, omit the -l4 option and the utility will repeat "Front Left Front Right" until interrupted with CtrlC. Then open another session and start alsamixer.

If there's a need, press the F3 to select Playback devices only. The output volume of the speakers is determined by mixer controls: Line Out and DAC which apparently stands for Power Amplifier Digital Analog Converter. The level of the latter was 100 on my system (although it says 95 above), and that of the former was about 79, if memory serves. Use the right and left cursor keys to select a control, and the up or down cursor key to set a value. The second Line Out (full name: Line Out Source) can be used to select between Stereo output or a very thin Mono Differential output.

Playing a WAV sound file is just as straightforward, if there's one on hand.

There are two hardware devices capable of playing sound on the OPiPC.

The first (index 0) sends analogue audio through the 3.5 mm jack. As can be guessed from what precedes, a DAC transforms the pulse-code modulation (PCM) data stored in the WAV file into an analogue signal. The second device sends sound to the HDMI connector, presumably using an IIS (Inter-IC Sound) serial bus which sends the PCM audio data straight through. Apparently both are default playback devices.

Is selection of the output device automatic as on a Raspberry Pi? I could not find an ALSA configuration file. Usually it is named asound.conf and it is stored in the /etc directory.

Recording Sound

I tried recording sound with the on-board microphone.

There is an easy fix. In the other session, select the capture controls by pressing the F4 key.

Notice how there is no visible control for the actual sound devices. That makes sense for Mic2 because there is only one on-board microphone on the OPiPC2 even though the H5 has two microphone inputs. Select the Mic1 control with the left or right cursor key and press the SPACE bar. The microphone will be turned on and this is indicated with L   R / CAPTURE above Mic1. The recording level is adjusted with the Mic1 Boost and the ADC Gain mixer controls. Thank you to kutysam in the Armbian Forum for those instructions.

Of course, aplay can be used to playback the recording to make sure it worked.

The Record from mic page on the ALSA wiki has instructions on how to control the capture device using the command line utility amixer instead of alsamixer. First list the available controls.

It is possible to get the status of microphone 1, and then to enable capture using it. The recording level is set with the Mic1 Boost and ADC Gain controls.

To turn off capture is just as easy.

Bluetooth

As stated in the introduction, the good news was that the Bluetooth dongle was recognized by Armbian. The Bluetooth (BT for short from now on) was not installed.

As suggested, it was a simple matter to install BT.

From experience, it's best to add the default user to the bluetooth group to avoid having to use sudo when running the bluetootctl. The session has to be closed and reopened to actually updated the group membership.

Now is a good time to check that the bluetooth service started automatically during the boot process.

It was not possible to connect with a BT speaker although it was possible to pair with it.

Not unexpectedly, BlueALSA was not installed. It gets worse, bluealsa is not available in the repository.

It will have to be built from source.

Compiling BlueALSA

The first steps consist in installing build prerequisites and then the required libraries.

Get the archived source for BlueALSA from GitHub and extract it.

Then I just followed the instructions to configure and build the library. There are just four or five commands involved.

However there is a lot going on, so I kept a record of some of the details.

I was worried about the warnings at the end of ./configure. I found the following issue in the repository which made things a bit clearer.

Now I see, that this troubleshooting section is misleading. The --disable-thread-safety is a configuration option for alsa-lib >= 1.1.2, not for bluez-alsa. If you are using alsa-lib from a distro repository, the easiest approach is to define LIBASOUND_THREAD_SAFE=0 in your .profile file as follows:
export LIBASOUND_THREAD_SAFE=0

In the end, I did nothing about this, and so far it does not seem to matter at all.

Sending an Audio Stream to Bluetooth Speakers

Since there was no fatal errors when compiling, it was time to test that blueALSA in conjunction with bluez provides a solution for sound over BT. First start bluealsa in the background and then try to connect to a BT speaker.

The blueALSA "shim" or bridge between the bluez (the BT stack) and ALSA (the Linux sound module) is now running in the background and it's process ID (a.k.a. pid) is 10251.

That worked, now to play some sound, download a wav file to the board and start the mixer in a separate SSH session.

Back in the first session, attempt to play the wav file.

That worked. Since by default only the a2dp BT profile is activated by blueALSA, there is no need to specify it in the command line.

Playing an Audio Stream from a Bluetooth Device bt-sink

To test audio streaming in the other direction, it will be necessary to have speakers connected to the 3.5 mm jack or an HDMI monitor with built-in speakers (do stand-alone HDMI speakers exist?) and a source which is BT capable, such as a tablet or smart phone. I used an Android tablet on which a YouTube video was playing.

If blueALSA is still running, it will have to be stopped.

Now blueALSA has to be restarted but with command line options such that two profiles will be available, a2dp-source, which was available by default, and a2dp-sink.

Do not forget the sudo, I lost a lot of time because of that slip when checking with a second tablet. I will not go into the details of connecting the tablet with the OPiPC2 over Bluetooth. They depend on the operating system of the tablet. Even on Android systems, the details changed with different versions of the OS. On the OPiPC side, bluetoothctl has to be used to make the OPiPC discoverable and after the OPiPC and the tablet have been paired, usually on the tablet side, bluetoothctl on the OPiPC2 is used to connect with the tablet. Finally, the blueALSA player has to be started.

The speaker on the table should be disconnected because the sound will be sent to the OPiPC2 that will play it over the speakers connected to the 3.5mm jack. If you have an Android device, the instructions at ha/rpi/bluetooth_02_en.html#streaming could be of help. Remember that the OPiPC2 will show up as a BT device on the tablet under its hostname which is orangepipc2.

In those instructions it said that once the connection has been made, alsamixer could be used to set the volume of the sound out of the speaker connected to the OPiPC2. Here is what will be seen

Two mixers influence the volume of the sound playing through the speakers: Line Out and DAC. Furthermore the volume control on the tablet also determines the output volume.

The audio playback on the Orange Pi PC 2 lags behind the video playing on the tablet just as observed with the Raspberry Pi 3 B. On the other hand, I did not notice stuttering during the short tests done and thus there is no need to disable the Wi-Fi.

BlueALSA systemd Service File

A systemd service unit file has to be created to start bluealsa. Unfortunately, the simple unit file created in A Note on BlueAlsa 0.9 with BlueZ 5.43 on Rasbian Stretch will not be good enough because systemd cannot start it automatically. However the BlueALSA wiki has a page that provides detailed instructions on Using bluealsa with systemd. I followed the instructions to the letter and everything seemed to work well. When creating the unit file, /etc/systemd/system/bluealsa.service, the D-bus service file, /usr/share/dbus-1/system-services/org.bluealsa.service and the default options file /etc/default/bluealsa, don't forget to use the sudo prefix. These three files should belong to root and they are stored in directories not accessible by the default user.

Everything looks fine after booting; both the bluetooth and bluealsa services are running.

References

Once again, this is a post mostly composed of information collated from much more knowledgable persons. I had occasion to give references to some of their work on a particular topic. The contribution of others is wider in scope. Chief among these are Arkadiusz Bokowy and his collaborators who have created the Blueetooth Audio ALSA Backend variously called bluez-alsa and BlueALSA. Two Wiki pages on the repository were particularly useful Installation from soucre and Systemd integration. Finally, I should mention guidol who is quite active on the Armbian Forum because his February 15, 2018 post BlueALSA: Bluetooth-Audio using ALSA (not PulseAudio), showed that it was possible to stream BT audio in Armbian without installing PulseAudio, just as in Raspbian.