Posts Tagged ‘music’

New Audio Ripping Box

Posted: June 16, 2018 in Storing, Hardware, Audio
Tags: , ,

So the old Vortexbox is no more, the Atom 330 is so 32 bit that very little decent software now works on it. More by luck than judgement I managed to find an old micro-ATX board that has now been roped into service.

Given the variable quality of the music library, I’m seriously considering re-ripping everything to FLAC to ensure the best quality on the various playback devices we have.

So the question is – do I install Vortexbox (and perhaps get around to trying Bliss as well) or do I look at alternatives?

Itinerant fiddler…. so alternatives it is!

So far I’m looking at 3 options: Daphile, Vortexbox and dbPowerAmp.

First up Daphile

Daphile is a Gentoo based distro that does basically the same as Vortexbox. It is much more locked down as there is no access to the underlying system, and there are no additional services that can be added to enhance the functionality. It rips CDs as FLACs and adds them to the onboard LMS server. It does support LMS plugins btw.

The UI is much more polished than VB, with very little effort I can configure it to rip to my unRAID server where our music is actually hosted. I can specify the quality of the FLAC, schedule backups of the local music folders and even access Jivelite to control local playback.

Metadata is added but only via a single source (I can’t remember I’ll add it later!) and has mis-identified a couple of CDs.

What it doesn’t do…. No DVD ripping, no Plex, Subsonic or Bliss servers. It doesn’t allow you to rip to FLAC and then automatically create mp3s as well.

Generally I like it, I’m in two minds about keeping it but I have a couple of issues.

  • The inability to also create mp3 files from the same source at the same time
  • Metadata quality
  • Inability to configure naming convention for the output

If I’m just re-ripping for FLAC, then it will do the job very well, but I’ll still need to do manual work to rename and check the metadata. As there are several hundred CDs, that’s not great.

Next up Vortexbox.

Advertisements

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.

Audio Ripper

Posted: March 2, 2018 in Audio, Hardware
Tags: ,

So the Vortexbox ripper is on its last last legs, doesn’t update anymore and I’m finding that the metadata matching is occasionally ‘off’.

Looking around it looks like XLD on the Mac is my best option for ripping new stuff, I like the look of dbPowerAmp (used to use it years ago), but I’m not sure that I need to buy software.

Bliss is looking like a good choice to try and fix the issue in the library, I must try it out properly.

Rediscovering Music

Posted: December 17, 2017 in Audio
Tags:

Our music collection is very variable in quality. A variety of ripping software, quality settings and knowledge has led to a lot of differences between early rips and later ones. I’m finding this out the hard way when I play stuff back in the car!

This is compounded by later rips being done to FLAC and then to mp3. Our Sonos is also pointing at the mp3s rather than the FLACs which does seem to be a bit silly.

The default ripper in the last few years has been Vortexbox, but the hardware that it runs on is old and will very soon probably stop getting updates. I’ll need to figure something out.

Mobile Music Player

Posted: November 20, 2017 in Audio
Tags:

Commuting to work by train used to mean that I had plenty of time to listen to music. When I started driving to work, it became much more difficult to do as my old car was still only equipped with basic FM radio and a cassette deck.

Installing an adapter was difficult and not worth the effort and cost to be honest, so my daily music was reduced to radio only.

My car has died now, so the new VW I’ve had to buy at least comes with a DAB radio and allows for an SD card with mp3 files.

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?

usecase3

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.setmode(GPIO.BCM)
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)

try:
    while 1:
        clkState = GPIO.input(clk)
        dtState = GPIO.input(dt)
        if clkState != clkLastState:
            if dtState != clkState:
                volume += 1
            else:
                volume -= 1
            changeVol(volume)
        clkLastState = clkState
        sleep(0.01)
finally:
        GPIO.cleanup()

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.

usecase4

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-drawing

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.

usecase1
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

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)

button = 20

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

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

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

mpc

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

To

mpc toggle

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

usecase2

Play/Pause, Stop, Previous & Next

Python Code:

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

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

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)

#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")
  subprocess.call(['mpc', 'toggle' ])
 elif GPIO.input(stop) == GPIO.LOW:
  print ("Stop")
  subprocess.call(['mpc', 'stop' ])
 elif GPIO.input(prev_track) == GPIO.LOW:
  print ("Previous")
  subprocess.call(['mpc', 'prev' ])
 elif GPIO.input(next_track) == GPIO.LOW:
  print ("Next")
  subprocess.call(['mpc', 'next' ])
 elif GPIO.input(power_off) == GPIO.LOW:
  print ("Shutdown")
  #os.system("sudo shutdown -h now") # Send shutdown command to os
 else:
  #print ("Nothing")
  pass

 time.sleep(0.25)
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:

GitHub: https://github.com/nwootton/HiFiPi

Reset Switch – http://www.raspberry-pi-geek.com/Archive/2013/01/Adding-an-On-Off-switch-to-your-Raspberry-Pi