Bluetooth Audio Receiver (Raspberry Pi Version)

This is a story about Raspberry Pi (Hereinafter as RPI) Bluetooth receiver module making project that has gone too much complex.

Therefore, I don't recommend anyone try to make the receiver module the same way as I do in this story.

Just considers this project as a referential example of making the Bluetooth audio receiver with RPI as an unnecessarily complex way. (But I suppose RPI base project can’t be simpler than this)

Already, I had introduced the same Bluetooth audio receiver circuit in the previous Instructable below.

https://www.instructables.com/Bluetooth-Audio-Receiver/

Before I knew that such a one-chip solution (MH-18M) is already available, I tried to make a Bluetooth audio receiver module with RPI.

As I have a HiFiBerry DAC board, my idea for making the Bluetooth audio receiver module is like below.

- RPI BlueALSA module to connect a smartphone via Bluetooth as the music source

- The BlueALSA also redirects the audio stream from a smartphone to HiFiBerry DAC.

- HiFiBerry DAC converts digital audio streaming into an analog audio signal to drive a power amplifier.

Besides the above main functionality of the Bluetooth receiver module (Hereinafter as RECEIVER), I had included the following auxiliary functionalities to the RECEIVER circuit.

- LCD showing status of RPI operation

- Cooling FAN circuit to regulate RPI CPU temperature

- Installing dedicated internal 5V power supply modules

When you compare the two same functionality of RECEIVERs in the picture above, you may curious why the RPI version seems so much complex.

Let's look at the details about RECEIVER utilizing RPI instead of the one-chip solution such as MH-18M.

Step 1: Schematics and Parts

When you use RPI as the controller of your intended device, various auxiliary components are required as follows.

- Internal or external power supply at least supporting 5V 3A capacity

- Cooling FAN circuit to monitor CPU temperature and cool down when temperature exceed your defined threshold such as 60 or 70 degree

The power supply is mandatory as stable RPI operation is highly dependent on a reliable power supply.

Meanwhile, cooling FAN can be optional as RECEIVER functionality is not requiring so much RPI computing power.

When looking at documentation from the RPI foundation, RPI is still operational even with the CPU temperature exceeding 80 degrees.

But I'm also thinking of several background jobs that are run together with RECEIVER functionality.

That's why the cooling FAN circuit is added with its own power supply components. (Small AC 220V to DC 5V power supplier)

Previously I received a question from someone asking why separated power supply modules are used for RPI and cooling FAN.

He thinks using two independent power supply is seems expensive and overkills for a simple RPI project.

The reason is high-speed cooling FAN of more than 4000rpm draws a significant current while operating such as 500~700mA.

Then power supply voltage can be decreased from 5V to less than 4.5V immediately while a motor of FAN is running.

Then RPI reports an under-voltage error and some abnormal operations are occurring.

Therefore, I'm completely separate inductive cooling FAN load by assigning dedicated power supply and motor running does not make problem to the RPI power supplying quality.

As I2C 16x2 LCD module interfacing is a very common configuration, I will not explain the details.

But connecting HiFiBerry DAC requires some explanations as details are described in the step next.

Step 2: Hardwiring HiFiBerry

Usually, HiFiBerry is directly plugged into RPI like many HAT kinds of boards.

But as I need to cool down the RPI for the RECEIVER project, the HiFiBerry DAC should be connected with RPI in some different ways.

As the cooling FAN should be mounted right above the RPI, HiFiBerry is connected by Dupont wires as shown in the picture above.

The HiFiBerry DAC is commonly used by hobbyists who expect some more high-quality audio sound from RPI.

I will not explain the basic HiFiBerry installation details as an upgraded Raspbian (Buster) includes the DAC device driver and configuration become simpler than previous versions. (Stretch, Jessie)

For the RECEIVER project, only the hard wiring between DAC and RPI becomes an obstacle that should be handled properly.

You can share I2C control pins (pin 3-GPIO2, pin5-GPIO3) between 16x2 LCD and HiFiBerry DAC.

As the I2C bus support single master (RPI) and multiple slave devices (16x2 LCD and HiFiBerry DAC), there is no problem for character displaying by LCD and music playing with DAC at the same time.

Regarding cooling FAN control circuit details, you can refer to the following instructable.

https://www.instructables.com/Raspberry-Pi-Box-of-Cooling-FAN-With-CPU-Temperatu/

As this project is for making the RECEIVER (Audio processing circuit) module, let's focus on the audio handling DAC board for more detail.

I'll explain the basic settings to make HiFiBerry as a single designated audio sink for the RECEIVER in the next step.

Step 3: Configuring HiFiBerry

When comparing the plug-and-play Windows-style audio configuration, Linux requires relatively complex procedures such as installing several packages, setting several configuration files, and verifying the operational status with several administrative commands.

When installing HiFiBerry, the default RPI sound devices are disabled.

Also to make HiFiBerry as default audio sink (Audio output device), /etc/asound.conf configuration file should be modified.

As a result, the available audio output device check command ("aplay -l") will list only HiFiBerry.

Then you can test the HiFiBerry operation by entering the following command.

- aplay /usr/share/sounds/alsa/Front_Right.wav

The aplay supports only playing wav (not mp3) files and you can hear female voice announcement from the speaker.

Also as shown in the picture above, "aplay -l" and "alsamixer" command output should display the installed HiFiBerry DAC device (snd_rpi_hifiberry_dacplus) on the screen.

When HiFiBerry testing is completed, basic sound hardware install and configuration are finished.

For supporting Bluetooth audio receiving functionality, the following software install and configuration steps are necessary.

- BlueZ and Pulseaudio installation, setting, and troubleshooting

- Streaming Bluetooth audio from smartphone to RPI using ALSA

The package installation, configuration, and administration details will be explained at the next steps.

Step 4: Install, Configure and Troubleshooting of BlueZ and Pulseaudio Demons

As Linux audio management system is very complex, I will not explain basic technical details in this story. (It's a really long story and very complex)

But as a summary, BlueZ (Including Blue-ALSA) is the Bluetooth communication support and audio device interfacing package.

Meanwhile, PulseAudio is a kind of audio processing middleware that supports high-level services such as audio streaming control, audio data manipulation (multiplexing, transformation) support, and so on.

Somehow there seems software bugs exist in the Buster raspbian OS version.

For correctly installing, configuring, and administrating BlueZ and PlusAudio, several troubleshooting works are required as details are explained on the website below.

https://peppe8o.com/fixed-connect-bluetooth-headphones-with-your-raspberry-pi/

I will not explain in detail "How-to"s as described in the webpage above.

If following the directions as written on the webpage, the Bluetooth demon will be correctly running without errors as shown in the screenshot above, and pairing with your smartphone will be completed.

I'm following the written directions of the above webpage every time whenever I'm working with any Bluetooth-based devices such as headphones, speakers, and receiver modules, and so on.

Step 5: Streaming Bluetooth Audio From Smartphone to RPI Using ALSA

When you complete all the above steps, HiFiBerry is correctly running and Bluetooth operation is properly configured and readily serviceable.

The next step is configuring the smart Bluetooth communication protocol called A2DP as well as redirecting the audio streaming from the smartphone to HiFiBerry.

Please refer to the detailed directions in the webpage below for the A2DP enabling and redirecting audio streaming.

https://scribles.net/streaming-bluetooth-audio-from-phone-to-raspberry-pi-using-alsa/

If you complete all relevant instructions written on the webpage above, played music from your smartphone should be transferred to HiFiBerry.

As a result, you can hear played music from the amplifier speakers.

Step 6: My Settings Correctly Supporting RECEIVER

To make this story clear and un-confusing, I didn't mention quite the details of "How-to" and introduce the relevant web pages instead for your references.

As supplementary information, I'll show detailed configuration results of the RECEIVER which running correctly.

The picture above shows RPI RECEIVER in action and actually playing music of audio streaming from smartphone.

After installing and configuring HiFiBerry to RPI, device status and operational situations are as follows.

- “aplay –l” command show the following output

**** List of PLAYBACK Hardware Devices ****

card 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC+ HiFi pcm512x-hifi-0 [HiFiBerry DAC+ HiFi pcm512x-hifi-0]

Subdevices: 0/1

Subdevice #0: subdevice #0

- Contents of “/etc/asound.conf” like below

pcm.!default {

type hw card 0

}

ctl.!default {

type hw card 0

}

After installing and configuring BlueZ and PulseAudio, demon operation status and major system settings are like below.

- When running “sudo systemctl status bluetooth.service” command, the following should be displayed

● bluetooth.service - Bluetooth service

Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)

Active: active (running) since Fri 2021-12-03 20:00:07 HST; 3h 19min ago

Docs: man:bluetoothd(8)

Main PID: 600 (bluetoothd)

Status: "Running"

Tasks: 1 (limit: 2059)

CGroup: /system.slice/bluetooth.service

└─600 /usr/lib/bluetooth/bluetoothd --noplugin=sap

Dec 03 20:00:07 receiver systemd[1]: Starting Bluetooth service...

Dec 03 20:00:07 receiver bluetoothd[600]: Bluetooth daemon 5.50

Dec 03 20:00:07 receiver systemd[1]: Started Bluetooth service.

Dec 03 20:00:07 receiver bluetoothd[600]: Starting SDP server

Dec 03 20:00:07 receiver bluetoothd[600]: Excluding (cli) sap

Dec 03 20:00:07 receiver bluetoothd[600]: Bluetooth management interface 1.18 initialized

Dec 03 20:00:10 receiver bluetoothd[600]: Endpoint registered: sender=:1.26 path=/MediaEndpoint/A2DPSource

Dec 03 20:00:10 receiver bluetoothd[600]: Endpoint registered: sender=:1.26 path=/MediaEndpoint/A2DPSink

- With bluetoothctl, paired devices should display Bluetooth address of your smartphone as below.

# bluetoothctl

[G6] paired-devices /* My smartphone is LG G6 */

Device 88:36:5F:5E:11:A8 G6 /* Show my smartphone Bluetooth address */

After configuring A2DP and streaming redirection, demon operation status and major system settings are as follows.

- Look at configuration file setting with “sudo vi /lib/systemd/system/bluealsa.service”

ExecStart=/usr/bin/bluealsa --profile=a2dp-sink

- When running “sudo systemctl status bluetooth.service” command, the following should be displayed

● bluetooth.service - Bluetooth service

Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)

Active: active (running) since Fri 2021-12-03 20:00:07 HST; 3h 26min ago