Blog Articles and information on C# and .NET development topics

In my previous Argon ONE review, some of the photographs show a pair of white cables, one going into a USB slot and another the audio jack. These belong to a set of Logitech Z120 speakers I'd bought for use with things like the Raspberry Pi to avoid more plugs.

Unfortunately however, I swiftly discovered that these are not a very good fit for the Pi - when they are plugged in and switched on, there is constant feedback issuing from the speakers. I considered buying another pHAT BEAT but I decided that was overkill - I don't need hardware audio buttons nor a VU meter for a "desktop" Pi. But although that particular board was overkill, perhaps another board with less features would be suitable - the board would power the speakers so I could still be plug-less.

As always, I chose and bought these items myself, no-one is asking me (or paying me!) to write this content. There are no affiliated links.

In the end, I settled on the Adafruit I2S 3W Stereo Speaker Bonnet for Raspberry Pi, paired with the Pi Hut's Enclosed Stereo Speaker Set (3W 4 Ohm). I choose these speakers as firstly, they are a pair, secondly they are enclosed so less likely to be damaged if I leave them bare and thirdly they include the necessary cabling which will plug directly into the bonnet.

This article describes my initial thoughts and experiences - I don't know if it qualifies as a review per se, so I'll leave it at thoughts, and potentially follow up later if there's a need.

The board is the same size as a Raspberry Pi Zero so I have no really idea why they called it a "bonnet" instead of a "hat". The kit includes the board itself, a half-height 40 pin GPIO header already soldered in place, a speaker jack in the middle (I don't know its official designation), and two additional headers for allowing you to use traditional wired speakers. And, unlike the pHAT BEAT, these headers let you screw the wires into place. However, they weren't pre-soldered so you would need to do this yourself. This is both a blessing and a curse I suppose as they are about double the height of the pre-soldered jack so if you do solder them on they will increase the total height of the board.

The speakers appear to be quite nice. The enclosure feels solid, and the speaker parts are inset slightly so hopefully less likely to get damaged. The cable is around 45 centimetres long, so if you fully split it you could have the speakers almost a meter away from each other. Nothing fancy, no extra's, just a small pair of speakers and their cable.

Note: In all pictures you'll notice that the speakers are plugged into the bonnet. I plugged them in prior to taking photographs and it is wedged solid, I doubt I can separate them again without damage.

I had to admit to a moment of concern when I thought the board wouldn't fit as the GPIO slot is inset in the case due to the magnetic hatch, but I need not have worried - the designers of the case have apparently planned for this and it nicely fits facing backwards.

Except, to jump ahead a little, there's a massive problem with the design. I mentioned earlier that the GPIO header was half-height - the plastic header is 4mm high, compared to 8mm on other devices. This means that when you push it into the slot on the case, you can easily push it in enough so that it is resting on the top of case. Twice when I did this I actually saw sparks in the bottom right of the recess, a third time I evidently shorted something and the Pi rebooted.

All of the photographs in this article show the bonnet almost flush with the case, but rather unsurprisingly this was not something I was willing to tolerate. As the header was pre-soldered and I still don't have a soldering iron, I grabbed a 40 Pin GPIO 2x20 Female Header from eBay, plugged that into the GPIO slots on the case and then the bonnet into that, pushing it far enough above the case that there's no chance of further contact.

Of course, it sticks out like a sore thumb so maybe I should look for a new case that can contain both the Pi and the bonnet. Shame though, the Argon ONE is a fine looking case. Except apparently not as durable as I thought given it is now sporting a very visible scuff or scratch caused by who knows what.

Just like with the pHAT BEAT, a handy installation script is available that will re-configure the system to use I2S digital sound rather than the onboard chip. The installation script can also install a service that will always "play" inaudible audio when the sound card isn't otherwise in use to prevent popping.

Installation is in theory simple, just run the following command to download and execute the script, then answer the questions it asks.

You probably shouldn't blindly paste command lines you get off some random blog, but should always check the script before running it.

curl -sS https://raw.githubusercontent.com/adafruit/Raspberry-Pi-Installer-Scripts/master/i2samp.sh | bash

So I did say in theory. As I had bought an 8GB Pi, and a beta version of 64bit Raspberry Pi OS had been released, I had made that my daily driver when trying (and, it has to be said, mostly failing) to perform development activities on the Pi. It might be beta but up until now I've had surprisingly few issues, I think the worst I've seen is screen tearing when watching films via VLC Player.

However, this script isn't compatible with the 64bit OS - it throws an unsupported hardware error. After examining the script and then tinkering it slightly to skip the hardware check, I ran the script again but the speaker tests failed and I couldn't play audio.

I next followed the manual instructions but still had a severe case of no audio.

One of the great advantages of the Pi is you can just swap the SD card and have a completely different operating system or configuration. I flashed a fresh install of 32bit Raspberry Pi OS onto a spare SD card and booted it up.

This time the script ran without a hitch, although it claims that Buster is experimental. This is yet another cause for concern to me - the script hasn't been touched for 15 months, yet the board is still being sold. In fact, when I checked the source, it classes Stretch is experimental and that was released in 2017. If you are actively selling a product, then you should damn well be keeping your install up to date.

Digression aside, everything went smoothly on the 32bit OS. There's a slight oddity in that you need to reboot after setting up I2S, play audio, then reboot again in order for tools such as alsamixer to work, but you only need to do that the once.

However, I did quite quickly note that the default volume control that appears in the taskbar (Volume Control (ALSA/BT)) didn't work properly. When you clicked the volume icon, it would display a No volume control on this device tooltip instead of presenting a volume slider. Right clicking and choosing Output Device Options shows a dialogue that includes a volume slider, but that is not entirely optimal for quickly changing the volume. Happily, I knew from previous poking around that there are two volume controls available for the taskbar and so I added the other one (Volume Control) and this worked absolutely fine, presenting the slider without issue.

Clearly the bonnet and the speakers, were working fine, but what about the quality? I tried playing a film via VLC Player and immediately noticed there was no real depth to the audio, a distinct lack of bass.

But, there was no feedback at all... when I wasn't playing audio, nothing was issued from the speakers.

The speakers aren't the best quality but they work.

Although I will be using those small speakers for the foreseeable future, I wanted to verify that the quality issues were due to them and not the board itself. I plugged in one of the speakers I use with my Pi Zero music centre using one of the optional speaker headers (fortunately I could hold it in place to test). As I mostly expected, the audio coming out of the speaker was deep and clear.

I was curious as to why 64bit hadn't worked - it didn't really make a huge amount of sense. I'd checked the script and it was just changing configuration files, not installing software or anything like that.

So, I restored my 64bit image and tried again. First, I followed the manual procedure. No audio. But when I right clicked the speaker icon in the taskbar, I realised that the snd_rpi_hifiberry_dac entry wasn't ticked the way it was for 32bit. I have no idea what device it was trying to use, but clearly it wasn't that one!

On running the speaker test after checking the dac option, everything was fine. So I tried a video and that played fine too. Success?

Yes and no. Each time audio stopped or started there was a popping noise... that would get annoying just as fast as the feedback on the USB powered speakers and explains why the script tried to set up a service. So...

I decided to restore my backup image again and retry using the script now that I've seemingly discovered that a default device wasn't being set up. I commented out lines 145 and 147-150 and executed the script. After the first boot, I set the default output device to be snd_rpi_hifiberry_dac, ran the script again (opting to install the little service) and rebooted again.

And... no sound. But interestingly, VLC Player displayed an error dialog stating that the audio was in use. The most obvious cause was the helper service, so I disabled that and rebooted. And now I have audio again, complete with pop.

I also noted that I couldn't change the volume at all. Sigh.

I was typing this article up in VS Code on my desktop computer, the Pi with the 64bit OS was playing Tim Burton's Batman. I had paused it while working on this draft when after around 20 minutes or so the speakers started squealing. When I touched one of them I was shocked at the temperature - they were really hot. I immediately powered down the Pi.

Now I've watched several films on this Pi over the last few days using the fresh 32bit install, including leaving films paused for hours while working and I have never had any squealing issues or problems with heat. In fact, after swapping the cards around again, booting into 32bit, and then waiting until the speakers had cooled down, I tested the same scenario without issue.

Is this a 64bit issue? A side effect of not running the always on service? Some random conflict with other software I've installed? I don't know. But I am definitely concerned enough that I won't be using it with the 64bit Raspberry Pi OS again.

I would rather not have had to purchase this board, but the feedback from the USB powered speakers meant I needed another solution. Software issues aside, I'm quite happy with this bonnet.

I suspect I'll probably want to look into changing cases though as I don't like the aesthetics of having this board poking out like the spoiler of a car, not to mention the shorting out if the pin slots on the board come into contact with the metal case.

And the speakers, while serviceable, aren't great for watching films. I most likely will try and replace them with a smaller set of second-hand traditional hi-fi speakers from eBay which I can wire directly into the board.

Finally, I clearly need to rethink if I'm going to stick with the 64bit OS. I've spent a lot of time customising it and installing various bits of software, none of which I documented after the first day. But there seems to be too many issues with this board when used on the 64bit OS for me to want to continue with it.

← Previous: Committing to a Git repository using custom dates

While we appreciate comments from our users, please follow our posting guidelines. Have you tried the Cyotek Forums for support from Cyotek and the community?

Your name:

Your email address: (optional, will never be displayed)

Your URL: (optional)

Comments

Comment

Styling with Markdown is supported

Submit