Archive for the ‘Hacking and playing’ Category


Posted: July 2, 2018 in Audio, Hacking and playing, Storing
Tags: ,

Bliss describes itself as a tool to fix the metadata in you library:

“bliss performs all the hard work in organizing your music collection; making it consistent, correct and complete with little effort.”

You define a set of rules about how certain key elements of your library should be. At it’s most basic this can be checking that the album artwork is present, of a minimum or maximum size, specific format and name. Additional rules define that the folder structure is correct, that certain tags are present and even if there are duplicates.

It basically scans your music library and then tells you which albums have failed to meet the requirements set out in the rules. It then offers to apply a ‘fix’ for each non-compliance.


Compliance Report (Images courtesy of bliss)

You can point it at your whole library and just let it get on with the scan and then come back a few hours later to see the results.


Initially installing and testing the app gives you 100 free fixes, with 250 additional fixes costing £12, 2500 fixes for £29 or Unlimited fixes for £59. You can buy as many or as few fixes as you need, although best value is definitely the Unlimited fixes for £59.


Some fixes are automatic – updating artwork is one of those… so while I pointed the app at the new rips directory that was being populated by VortexBox, it suddenly started using fixes to download the artwork. My own fault, I should probably RTFM, but I did wonder why fixes were being used without my ‘authorisation’.

Of more concern was the use of multiple fixes to fix the same missing artwork – I’ve contacted the creator to see if this is a known issue and I’ll report back.


So far I like what it is doing, but I’m reserving judgement to see a) how it handles bulk FLACs b) if the issue I experienced is solvable or just me being stupid 🙂



Images courtesy of Bliss

Prices correct as of June 2018 – Pricing page is here

** UPDATE **

2 July 2018 – I’ve been speaking to bliss support (& Dan the creator) about the issue. Nice fast response to my query and it appears to be bliss being a little too enthusiastic about doing stuff. My issue of using multiple fixes for the same album looks like it was caused by bliss finding the first file, fixing it, finding more files in the same folder, fixing them and then finding the remaining files.

I need to figure out how I can prevent bliss from scanning the folder structure until I’m ready – i.e. all my FLACs have been copied to the destination folder.



I know, I got distracted again…. New versions of OpenHAB2, so trying to do a new clean build of my house automation – getting rid of all those items I’ve started to add and then never got around to removing afterwards.

I’m starting to look at ways to actually build this mishmash of ideas in the real world rather than on a breadboard. Although I bought some plain protoboards, it suddenly dawned on me that I had actually no idea how I would physically build this!

First question – how do I distribute the GND and 3.3V lines? In a breadboard there are rails along each side, but in a protoboard there’s no such thing. After some minor panic I eventually found something called a permaboard that basically resembles a breadboard, but allows you to solder on to it.

Next question – how do I connect the Pi GPIO pins to the permaboard? I’m guessing that I can get some kind of cobbler to connect the GPIO pins via a ribbon cable to the cobbler soldered on to the permaboard, but I don’t need all the pins and I’d rather just have the pins I need exposed on the permaboard. It also means that the permaboard could be smaller.

My initial idea is to use a 40-pin ribbon cable with a fixed connector for the GPIO and individual female connectors at the other end (see here). If I solder sets of breakout pins to the permaboard, I can connect the female ribbon ends to the board that I need and leave the other ones hanging around. As the connectors are female, the chance of them shorting out something if the flop around is much, much less!

I’ll try and find some time and report back.

So I’ve gone through two use cases so far, and I have successfully got these working using the basic plug and play parts of an introduction to electronics kit. No soldering, just pushing pins into the prototyping board. The next couple of use cases I think I’ve figured out, but as the cheap electronics are coming from eBay via China, I’m still waiting for the parts to arrive before I actually try these ones….

So this is (at time of writing) all theory!

Use Case 3 – Volume Control

While the X400 has an on-board volume dial, I’m not convinced that I can build a suitable mechanical coupling to allow me to expose this outside of the enclosure. My gut reaction is to use this as the max level control and then use software to control the volume up to this hard limit. Volumio will then treat this as the 100 (max) point in its volume scale and allow users to set volumes. Volumio can also set the mute the same way, but how do I control the volume?

I believe that I can control the volume via the software mixer in Volumio. Like with mpc, I should be able to issue a command to increase or decrease the volume. As with my previous two use cases, adding a switch to the GPIO and detecting it appears to solve this problem.

Adding another set of switches seems ‘wrong’…. So perhaps I should try something a little bit more complex and user friendly? Maybe using a rotary encoder (a dial!) instead to control the volume? Maybe I should be really smart and try a rotary encoder with a push button (a dial you can click) to allow for mute as well?


Rotary Encoder – NO Switch

Python Code:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from RPi.GPIO import GPIO
from time import sleep

#Define GPIO Pins that have buttons
clk = 5            #volume dial clk
dt = 6             #volume dial dt

GPIO.setup(clk, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.setup(dt, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

volume = 0
clkLastState = GPIO.input(clk)

def changeVol(newVolume):
    print ("New volume is " + newVolume)

    while 1:
        clkState = GPIO.input(clk)
        dtState = GPIO.input(dt)
        if clkState != clkLastState:
            if dtState != clkState:
                volume += 1
                volume -= 1
        clkLastState = clkState

Update: The encoder I have has 5 pins, not 3…. clk/dt/GND/3.3V/something…. and that is represented in the code above. It still doesn’t have a ‘switch’.

Update: The latest version of Volumio has its own command line client that allows for volume setting.

volumio volume <value>

Use Case 4 – Radio Stations

The final use case is the ability to switch to live radio streams – something that is a must in a kitchen radio! I think we’re back to simple GPIO buttons on this one, with each one triggering a predefined playlist of a single stream. How we trigger the actual stream is something I’ve yet to figure out.


Radio Preset 1, 2 & 3

Still working on this bit…. #sigh


Use Case 5 – Modes

OK, so I lied. While playing with the HiFiPi I realised that the music is playing out of both the speakers and the headphone socket. As it was late and I didn’t want to wake the kids I needed someway to turn the speakers off. The X400 comes with 3 jumpers that are used to turn the amp on & off, the headphones on & off and mute all the outputs. Trouble is moving these around once inside the enclosure will be impossible.


X400 Output Jumpers

As these are fixed jumpers, it should be possible to use locking switches to fix the state in either open or closed, thus enabling the device component. A quick email to Suptronics support revels that this is true, so I now need to add locking switches to the shopping list to test.

This will mean I can add a mute button without using up a GPIO or adding code. The other two modes – headphones & speakers are more useful to me using the setup in the study at night. That way I can turn off the speakers and just use the headphones to stop me from waking the kids.

Parts List (so far):

Wire – whatever is appropriate to you setting!

2x 1 row pin headers

Momentary contact switch x1 – for ON

Momentary contact switch x1 – for OFF

Momentary contact switch x4 – Media shuttle commands

1x Rotary encoder

Momentary contact switch x3 – Radio preset buttons

Locking switches x3 – Mode output control

So now the real learning starts. I need to decide what I want the box to do, how to do it and then build it. Easy huh? The code that I reference here is also in my GitHub repo, it’s likely that these snippets get superseded as I figure out how the stuff works. I’m also using the excellent Fritzing to figure stuff out with the wiring, so it may pay to look at that as well if you want to design your own parts.

The other thing to note is that my switch circuits run from the GPIO Pin to GND – making the Pins use the PULL UP resistor in the Python code. If I had run the switches from Pin to 3.3V, PULL DOWN resistors would need to be declared.

As we are access the GPIO, all the python code will need to be run under sudo to gain access.

Use Case 1 – We must be able to turn the player On and Off via a switch

OK so after a lot of Googling it becomes apparent that all the normal method to deal with this – add on boards with switches – are inappropriate because of the X400. As the X400 provides power to the Pi, none of the aftermarket solutions will work.

Use Case 1 (Amended) – We must be able to turn the player On and Off

The answer (in theory) is to use the ‘reset’ switch header as an ON and to add a switch to the GPIO with some code to handle the OFF part.

There is a P6 header on the RPi boards that allows you to reset the device when it is shorted. While absolutely not suitable for a clean shutdown, it will restart the box if it is in a powered but shutdown state. The issue is that this header isn’t populated, so we will need to add some pins prior to connecting a switch of some kind. This means soldering the pin header to the board itself (gulp) and then connecting the new header pins to a switch. So that’s the ON part sorted.

For OFF, connecting a momentary switch to one of the GPIO Pins and then detecting it with some Python to trigger the appropriate shutdown command appears to be the easiest and safest method. This protects the SD card and ensures that everything is clean before shutting down. As power is still applied, we can use the new ON switch to restart when required.

Simple shutdown switch
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# Assumes switch is connected to GND - so uses PULL UP

import subprocess
import time
import os
import RPi.GPIO as GPIO


button = 20

GPIO.setup(button, GPIO.IN, GPIO.PUD_UP)

while True:
 button_state = GPIO.input(button)
 if button_state == GPIO.HIGH:
  print ("Shutdown")
 #os.system("sudo shutdown -h now") # Send shutdown command to os

Use Case 2 – Play, Pause, Next, Previous & Stop

So after some more Googling it seems that I can use the MPC client (the Music Player Daemon command line bit) to control playback from the command line. As Volumio includes this part, simply issuing commands allows us to control things via the terminal.

 mpc play

mpc pause

mpc stop

Issuing just


Will return a list of commands you can use.

So we’re back to the GPIO with an additional 5 4 momentary switches, each of which then uses Python to issue the appropriate mpc command.

** UPDATE **

Oops. While working on building the device modes (see Part 5), I realised that GPIO Pin 17 (Board Pin11) is already claimed by the IR receiver on the X400. This means that I have now lost my ‘play’ button. The solution is to remove GPIO 17 from the code and change the GPIO 27 (Board Pin13) from

mpc pause


mpc toggle

Which, unsurprisingly, toggles play/pause. The other advantage is 1 less button to fit somewhere on the final case!


Play/Pause, Stop, Previous & Next

Python Code:

# -*- coding: utf-8 -*-
# Assumes switch is connected to GND - so uses PULL UP

import os
import subprocess
import time
import RPi.GPIO as GPIO


#Define GPIO Pins that have buttons
play_pause = 27 #Play/pause mpc toggle
stop = 22 #mpc stop
prev_track = 18 #mpc prev
next_track = 23 #mpc next

power_off = 20 # sudo halt now

#Configure PULL Up and pin connections
GPIO.setup(play_pause, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(stop, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(prev_track, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(next_track, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(power_off, GPIO.IN, GPIO.PUD_UP)

#Begin loop to wait for button press
while True:
 if GPIO.input(play_pause) == GPIO.LOW:
  print ("Play/Pause")['mpc', 'toggle' ])
 elif GPIO.input(stop) == GPIO.LOW:
  print ("Stop")['mpc', 'stop' ])
 elif GPIO.input(prev_track) == GPIO.LOW:
  print ("Previous")['mpc', 'prev' ])
 elif GPIO.input(next_track) == GPIO.LOW:
  print ("Next")['mpc', 'next' ])
 elif GPIO.input(power_off) == GPIO.LOW:
  print ("Shutdown")
  #os.system("sudo shutdown -h now") # Send shutdown command to os
  #print ("Nothing")

Parts List (so far):

Wire – whatever is appropriate to you setting!

2x 1 row pin headers

Momentary contact switch x1 – for ON

Momentary contact switch x1 – for OFF

Momentary contact switch x54 – Media shuttle commands

Links & Refs:


Reset Switch –

In the previous two parts I’ve looked at building something a little more capable for audio playback. What I’ve built works brilliantly with headphones, but isn’t in any way  suitable for use by ‘normal’ people and definitely not with small children around.

So I decided to look at following the herd and try to build the new music player in an old enclosure. After much eBay hunting, I found several nice radios that could be refactored. My issue with them was the size.

If I want to build a stereo radio I need 2 speakers (obvious huh?), but most of these radios are mono, so adding a second speaker either means running two tiny speakers or modifying the case to allow for a second speaker. Either way two speakers take up space and the X400 is already considerably bigger than the HiFiBerry or equivalent board.

If I go the whole hog and try to include some form of interface/screen then a repurposed radio chassis is completely unsuitable. I can try and find a large (think valve type) radio from before the modern radio. These are generally quite large but come with wooden cases that can make the end product look gorgeous. This scenario gives me the opposite problem. The end product would be far too big to sit in the kitchen, it would be more appropriate for the dining room or somewhere as a centre-piece.

The X400 is rated to drive 2x 20W speakers, I had originally planned to buy some car speakers from eBay once I had the rough dimensions of the enclosure I wanted them to go into. So everything really hung off of finding a decent box to put it in.

Being a total novice at this stuff, I decided that it makes more sense to try and build something, learning as I go. I’d have to be prepared to completely get it wrong, throw away stuff and to start again. Once I’d figured things out, maybe then I could build the ‘final’ version.

With this in mind I decided I would get a broken Roberts Colourstream internet radio. While big and modern, it has a couple of decent speakers and a touch screen that I hoped I could re-use. The case should be big enough to fit everything inside and it is already configured for stereo.


Roberts Colourstream Internet DAB Radio

The previous owner had attempted to ‘fix’ the device – resulting in the guts basically being supplied in a separate bag, but that was just one less thing for me to do. Removing the facia allowed me to get to the speakers and after a couple of minutes work  I had stripped the plugs off the speakers and had wired them directly into the X400. A boot of the Pi and suddenly we have music from the speakers.

The next part is figuring out what I want to do, how to do it and what parts are needed!


So the X400 board arrived is a small cardboard box. The board was wrapped in an appropriate anti-static bag and the jumpers, nylon screws and standoffs were in their own little bag. No instructions in the box, but the website has pretty good documentation. Customer support is pretty rapid as well given the time difference between the UK and China when I did have a question.


X400 Image from Suptronics WebSite

As the X400 board also powers the Pi, it needs it’s own power supply. The docs say that it needs between 18 – 25 V supply that it then steps down to the levels necessary to supply the both devices. After rummaging around to find a suitable power supply, I ended up using an old laptop adapter that had the right size plug.

X400 itself fits on the RPi2/RPi3 via the 40 pin GPIO interface with nylon standoffs to support the card. There are also 3 jumper pegs in the box that allow you to turn on and off the headphones output, amp and to mute the audio. I guess these are used to disable the services you don’t want to use.

Volumio was the OS of choice based on my previous experiments with Audio OS’s, and as it supports the X400 card natively (an added bonus I found after reading the Suptronics website). As I already had an SD card built, I just used that. I didn’t do anything special to get the X400 working, although the Suptronics site talks about ensuring certain kernel modules are installed, I think these are more for older Raspbian versions. All I did with the Volumio build was select the correct device from the dropdown list in the config. page and it was all working!

At this point I got the new Volumio device to scan the FLAC library on the NAS and used it to playback some tracks via the headphone s. I’m not an audiophile, my FLACS aren’t the highest quality you can do and the headphones are cheap Sony ones I got from work a couple of years ago, but even with those limitations playback of a variety of tunes was impressive. Details and quality were much better that the ‘norm’ I’ve come to expect from high quality VBR MP3 via my iPod.

The only other thing I had to do was find a case. I’d seen some bundles that included the board and case, but I’d decided that the bundle was too expensive. After quite a bit of searching I actually only found one supplied who could get me an enclosure to protect the electronics. That was ordered from an Italian shop on eBay UK that then shipped the stand direct from China (isn’t international commerce great!?). This isn’t a case, but rather a clear stand with a top to prevent things coming into contact with live electronics – be they fingers or errant wires.

To be honest at this point I’ve completed the first and most basic version of my HiFiPi. If I can figure out how to do things like get power and channel selection buttons to work via the GPIO, find a suitable enclosure and speakers I’ll try and get the Kitchen Radio version built.

As usual I found myself with more ideas and things to experiment with when building the MooMusic prototype. Seeing all the possible things I could build made me want to move the project on far beyond my original ideas. But that wouldn’t be fair as the use case for MooMusic was very specific – a simple music player for my daughters. So I decided to use one of the various Pis floating around and try to build something more ambitious. I’d seen lots of people restoring antique radios or building small touchscreen enabled devices, so I wanted to do something like that.

First stop is to figure out the best way to get decent quality sound out of the Pi. Do I install something with a headphone style jack, something with phonos (RCA) or something that can take speakers? My initial thoughts were to install a DAC with some phono outs. If I wanted to use headphones I can easily get a phono-headphone adapter (assuming there isn’t one in my cable bin already!).

From the forums related to this kind of project it became apparent that HiFiBerry make some excellent small scale expansion boards that provide all of the connections I can think of and more. The prices aren’t bad either, and are cheaper than some of the true audiophile level DACs that I could try to use.

The problem is, I don’t actually have a real-world use case for this project: I’m not building this for a specific reason, just because I can. I soon realised that because I have no real use case, trying to build something that is suitable suddenly becomes much more complex. If I want speakers, I need an amp. If I want headphones I need a suitable jack. If I want to connect to an external amp, I need phono or maybe SPDif/Optical. Do I need to support Bluetooth? Will I use WiFi or ethernet?


After taking a step back I decided that I want this to either be my audio source in my office OR to replace the annoying kitchen radio. The actual outcome would depend on how easy to use the final thing was and how pretty it was.

Based on that it became apparent that I needed the ability to drive speakers AND the ability to output via headphone jack. Faced with this, the HiFiBerry boards became a bit too expensive for me to play with. ~£45 for the Amp and ~£23 for the headphone with no indication that I can stack them and use both boards in a single build.

I’m not confident that what I end up making will be good enough to use in the kitchen, so just buying the amp is risky.

While trying to resolve this matter I came across a reference to the X400 board. A bit more digging revealed the X400 board from Suptronics. This board includes phonos, amp (with speaker terminals) AND headphone jack. The downside is that all that requires a separate power supply. Thankfully the power supply also powers the Pi, so there’s no need to use 2 plugs! For ~£20 via eBay (of course) I ordered the board and crossed my fingers.