Bluetooth Audio Receiver (Raspberry Pi Version)

by jandb86 in Circuits > Audio

1496 Views, 1 Favorites, 0 Comments

Bluetooth Audio Receiver (Raspberry Pi Version)

00_Comparision.jpg

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.

Schematics and Parts

01_Schematics.jpg

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.

Hardwiring HiFiBerry

02_HiFiBerry_wiring.jpg

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.

Configuring HiFiBerry

03_Putty.JPG

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.

Install, Configure and Troubleshooting of BlueZ and Pulseaudio Demons

04_BlueZ.JPG

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.

Streaming Bluetooth Audio From Smartphone to RPI Using ALSA

05_Redirecting.jpg

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.

My Settings Correctly Supporting RECEIVER

06_RECEIVER.jpg

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

    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

Dec 03 22:35:03 receiver bluetoothd[600]: /org/bluez/hci0/dev_88_36_5F_5E_11_A8/fd0: fd(25) ready

The last line shows that audio streaming from my smartphone (LG G6) is redirecting to default sink (HiFiBerry).

 

If you have any problem with the correct operation of the RPI RECEIVER, visit each step from the HiFiBerry installation.

Please check administrative command result is the same as the direction written on the web pages.

If any error is encountered in the middle, the problem should be resolved before you proceed to the next step.

Otherwise, RPI RECEIVER will not correctly operate.

Actually, there is no RECEIVER operation-related information can be displayed on the 16x2 LCD as BlueZ automatically perform audio redirection with no helpful message.

Therefore, I'm only displaying uptime (how long RPI is running from booting) and CPU temperature information on LCD instead.

RPI RECEIVER Connection With TDA2050

07_Test_RPI.jpg

When every hardwiring and software configuration is completed, RPI RECEIVER is fully ready to act.

The newly-made RPI RECEIVER is connected with the TDA2050 power amplifier and my smartphone for playing music.

Although the first pairing with my smartphone requires manual setting of bluetoothctl commands, the subsequent connection shall be established automatically as BlueZ demon keeping address of my smartphone.

When playing music on the smartphone, aplay demon of RPI faithfully redirects the audio stream to HiFiBerry.

As HiFiBerry DAC uses a renowned Burr-Brown DAC chip, the output sound quality seems a little bit dynamic and detailed.

Although frequency details of the played song experiencing data loss while converted as a MP3 file, it sounds a little better than a one-chip RECEIVER module such as MH-18M.

Or is the Burr-Brown DAC chip included in HiFiBerry making slightly nice distortion?

I don't know and can't point out exact and scientific clues why RPI RECEIVER sounds a little bit better than the MH-18M.

Maybe very complex hardwiring and software configuring efforts I took before for making RPI RECEIVER flirt my mind to think it sounds nicer.

Testing MH-18M With TDA2050 Amplifier

08_MH-18M.jpg

Let's visit again of single-chip (MH-18M) based RECEIVER for the listening test.

Frankly speaking, I can't differentiate the sound quality of both RECEIVERs if I'm doing a blind test.

But when I'm testing the MH-18M receiver, it sounds a little bit flat.

Maybe my mind again compromising reality to persuade my ear feels the sound of MH-18M RECEIVER seems a little bit uninteresting. (in other words, lacking sound dynamics)

But one thing is quite obvious, making RPI RECEIVER is too much complex as details are introduced in this story.

Meanwhile, the MH-18M RECEIVER is very simple and supports affordable sound quality.

Conclusion

9_Better.jpg

In a conclusion, I recommend using MH-18M for the RECEIVER module if you want to make something similar.

But I already purchased 3 DACs and they are gathering dust while kept in my inventory.

Anyway, I'm supposedly utilizing these DACs along with RPI in the future.

Maybe I can add some more useful functionalities to the RPI RECEIVER such as showing song title on LCD or something.

This was a story about "How to make Bluetooth audio receiver (RECEIVER) module as a simple and good way (using MH-18M) or complex and difficult way. (using RPI and HiFiBerry)

 

Thank you for reading....