Preamble

Moode is my favourite way to listen to my digital audio library, not least because it has Camilla DSP built in, on which I depend to provide a parametric EQ correction curve to account for the tiny size of my listening room. Unfortunately my CD player does not benefit from this EQ since it is wired direct to my DAC. I wondered if I could connect my CD player to the Allo USBridge Signature digital streamer that runs Moode? It is based on a Raspberry Pi, after all, which is the ultimate in extensible computing devices, thanks to its HAT physical interface. I did some research and found a couple of Raspberry Pi HATs that offer S/PDIF input, and decided to go with the HiFiBerry Digi+ I/O.

I posted on the Moode Audio forums to see whether others had tried this, and the rather wonderful author of Moode pointed me to this rather excellent HOWTO from a user named Bitlab. My blog post is heavily based on his, but has some additions concerning getting the card recognized in the first place and the playlist configuration near the end.

Getting the S/PDIF input card’s driver loaded

I plugged it into the HAT connector, rebooted, then ssh’ed in to the rPi. Is the new device auto-detected?:

pi@moode:~ $ arecord -l
**** List of CAPTURE Hardware Devices ****

No, it is not. I found a guide at the HiFiBerry site to enable the driver for the HiFiBerry Digi+ I/O. The only step I did NOT follow was disabling the onboard rPi sound (i.e. I did not comment out the line dtparam=audio=on) else I found that Moode Audio would hang on boot.

So, is the card is now recognized:

pi@moode:~ $ arecord -l
**** List of CAPTURE Hardware Devices ****
card 2: sndrpihifiberry [snd_rpi_hifiberry_digi], device 0: HifiBerry Digi HiFi wm8804-spdif-0 [HifiBerry Digi HiFi wm8804-spdif-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

Success!

Configuring ALSA to use the card

Note the card, subdevice and subdevice parameter values (2,0,0 in my case), then get more details about this input device :

pi@moode:~ $ arecord -D hw:2,0,0 --dump-hw-params

Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:2,0,0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S24_LE
SUBFORMAT: STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [32 64]
CHANNELS: 2
RATE: [32000 192000]
PERIOD_TIME: (10 2048000]
PERIOD_SIZE: [2 65536]
PERIOD_BYTES: [16 524288]
PERIODS: [2 65536]
BUFFER_TIME: (20 4096000]
BUFFER_SIZE: [4 131072]
BUFFER_BYTES: [16 524288]
TICK_TIME: ALL
--------------------
arecord: set_params:1343: Sample format non available
Available formats:
- S16_LE
- S24_LE

We can use that information to set up an ALSA configuration file so that the system has means to address the card and input using convenient labels. I created /etc/alsa/conf.d/hifiberry_digi+_inputs.conf with the following content:

pcm_slave.digi_in {
pcm "hw:2,0,0"
rate 44100
channels 2
}

pcm.SPDIF_input {
type dsnoop
ipc_key 12342
slave digi_in
bindings.0 0
bindings.1 1
}

In the pcm_slave part above, I name my device digi_in then I use the same 2,0,0 card reference from above; you’d change that for your situation. 44100 as the sample rate since in my setup I’ll only be using it to play back CDs. 2 channels because that’s how many my device has.

In the pcm part, I name the input SPDIF_input and the slave parameter is the name of the device from above. See here for an explanation of the other parameter values, plus more generic instructions if your device has a larger number of channels.

Testing the card

To test whether this newly-configured input works let’s try and record from it. I plugged my CD player into the electrical digital input (on the HiFiBerry Digi+ I/O, inputs are the TOSLINK socket with the black dust cover and the RCA jack to its right), started a CD playing, then issued the following command:

pi@moode: $ sudo arecord -D SPDIF_input -f S16_LE -r 44100 -c 2 test.wav
Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

Here we’ve referenced the ALSA input defined above and once again specified CD audio format options. Ctrl-C will stop the recording. ls -l to check that test.wav is longer than 44 bytes (i.e. that there are actual samples in it beyond the file header info), then the following command to play it back:

pi@moode: $ aplay -D plughw:1,0 test.wav

This time the card reference differs since my playback device is separate from the SPDIF input card. I heard my recording play back. Success again!

Making the card available to the Moode UI

Next, this input needs to be made available to Moode in some way so as to control things via the UI and also to benefit from the room correction EQ curve. Cunningly, this can be set up using a playlist! M3U playlist files support hyperlinks, and MPD (the audio player within Moode) supports an alsa:// link format to play back directly from an ALSA source. I created /var/lib/mpd/playlists/CD Player.m3u, containing the following:

#ETM3U

#EXTINF:-1, S/PDIF Input
alsa://hw:2,0?format=44100:16:2

Note that this refused to work if I tried to use the identifiers I set up in the ALSA config above – I had to go back to the numeric references. Also, the EXTINF line is ignored so technically isn’t needed.

In the Moode UI, I navigated to the Playlists and hit the refresh icon. My new playlist was displayed, so I clicked the three dots then Clear/Play. Pressed play on the CD player and voilà, I was basking in newly-EQ’ed compact disc sound :)

Bonus point

It is possible to edit the playlist via the UI and upload an image file to make it look a little more integrated.

Drawbacks?

As noted in this HiFiBerry article, and also explained to me by IanCanada (who has made quite a name for himself with his no-compromise rPi audio solutions), the one probable drawback with this solution is jitter. Simply put, jitter is the difficulty in identifying when each bit of a digital stream begins and ends. In systems where the clock signal is sent separately from the audio stream, this is solved. In systems where the S/PDIF is connected directly to a good quality DAC, this is also solved since good DACs tend to ‘reclock’ the incoming stream in order to recover the correct clocking. There also exist ‘reclocker’ rPI boards that can recover the clock directly from the audio stream, but the kicker is that it is apparently not possible to pass the resulting stream from these to the rPi I2S bus, which is the only way to pass the audio to the operating system running on the rPi.

So then, I will perform some listening tests and report back on whether I can hear a loss in quality separate from the EQ improvements that were the whole purpose of this guide!