Low Cost Audiophile Music Servers

DIY Audio is getting a huge boost from two recent developments in the form of RuneAudio and Volumio which run on low cost hardware such as the Rasberry Pi and the BeagleBone Black. This new breed of music “appliances” constitute a step forward for music reproduction because they operate on  simpler single-board computers where the OS can be highly optimized for (only) music reproduction and stripped of all other unnecessary tasks.

Note: there are earlier implementation of multimedia software on these platforms -such as XBMC on Rasberry Pi-, but here we have audio-only implementations.

Both teams were working together and created the custom user interface, but due to some “chemistry mismatch” they split a while back. It is good to see however, that there is mutual respect and healthy competition between the teams resulting in better products ultimately benefiting the end user. You can read more here [link] and here [link].

As of this writing, the two projects share a common user interface (soon to diverge into their own versions), but use different UNIX flavor in their OS internals. Both use MPD [link] as the music server application.  Currently, Volumio supports I2S output, whereas RuneAudio will have I2S output in the upcoming 0.3 release.

USB INTERFACE TO THE DAC

The more “mature” way to interface the music server to a DAC is through its USB interface. I say “mature” because these interfaces have been available for a while and there are many solutions where in order to support bit-perfect playback, the audio clocks (the 44.1KHz and family; the 48KHz and family of frequencies) are generated by dedicated on-board oscillators.

However, there is still the driver consideration. Theoretically these interfaces should be supported by the OS (which are all Linux derivatives) without installing device specific drivers; but in practice this may not be the case. Here are potential interfaces: [link]

I2S INTERFACE TO THE DAC

The second way to interfacing to the DAC is through I2S which is a very appealing option because it “does away with another component” resulting in an even simpler solution: just the single board computer and the DAC. There is no need to transfer the audio data through the USB interface. The main concern here is whether or not the platform is capable of bit-perfect playback. Lets explore these in more detail.

BeagleBone Black (BBB) I2S output

BBB audio is generated by the main processor, the AM335x 1GHz ARM® Cortex-A8. The Multichannel Audio Serial Port (McASP) subsystem is responsible for generating the audio using and external audio frequency oscillator. In this case it is a 24.576 MHz oscillator connected to the clock input pin of the processor’s audio subsystem (See page 75 of the BBB System Reference Manual [link])

6.10.6 Audio Interface

There is an I2S audio interface between the processor and the TDA19988. Stereo audio can be transported over the HDMI interface to an audio equipped display. In order to create the required clock frequencies, and external 24.576MHz oscillator is used.

…

In order to create the correct clock frequencies, we had to add an external 24.576MHZ oscillator. Unfortunately this had to be input into the processor using the pin previously used for GPIO3_21. In order to keep GPIO3_21 functionality, we provided a way to disable the oscillator if the need was there to use the pin on the expansion header.

Because there is only a 24.576MHz clock, only the 48KHz family of sample frequencies can be supported. Seems audio (or bit-perfect audio – or perhaps “legacy 44.1K audio”) was not a big concern for the designers of the BBB. HDMI, which defaults to 48KHz audio was the primary concern.

Notice that If playing high res music, it can support 96K, 192K and also 384K (24576000/64=384000Hz)

Fortunately, GPIO3_21 is an expansion pin accessible from the outside and the on-board oscillator can be disabled by s/w.

The solution for bit-perfect audio is to provide the clocks externally through an expansion “cape”, using one or two other I/O pins to select the appropriate clock frequency (and the s/w driver that would enable the use of the external clocks) More discussion here: [link].

Rasberry Pi I2S output

There are some hints that the RPi is capable of of 44.1K output in the I2S interface. I can’t find a definite reference of bit-perfect playback. If I had a RPi I would just hook it to one of my ESS DACs and observe the actual sample frequency. Several I2S DACs have already been developed that seamlessly plug into the RPi expansion headers [link].

But is the RP1 I2S bit perfect?

In the RPi, the audio is generated by the Broadcom BCM2835 [link]  peripheral SoC chip. The audio frequencies are generated through an 0n-board 19.2 MHz oscillator. (Photo from here [link]).

If applying integer division to the clock, exactly 48KHz (and its family) can be supported. However, the highest sample rate that can be supported is

19200000/64=300KHz or effectively 192KHz.

According to the Datasheet, the Audio system is driven by a master clock “PCM_MCLK”. According to this thread [link], seems this master clock is generated internally by the clock generators. According to the Datasheet, the clock generators can use “fractional clock dividers”. The Datasheet indicates:

6.3 General Purpose GPIO Clocks

The General Purpose clocks can be output to GPIO pins. They run from the peripherals clock sources and use clock generators with noise-shaping MASH dividers. These allow the GPIO clocks to be used to drive audio devices.

The fractional divider operates by periodically dropping source clock pulses, therefore the output frequency will periodically switch between:

frequency source /DIVI & frequency source /DIVI+1

Jitter is therefore reduced by increasing the source clock frequency. In applications where jitter is a concern, the fastest available clock source should be used. The General Purpose clocks have MASH noise-shaping dividers which push this fractional divider jitter out of the audio band.

Thus, fractional dividers can be used to generate the 44.1K frequencies (or rather 44.1Kx64 for the bitclock) by using the above built-in method. Audiopurists would cringe at the “periodically dropping source clock pulses” part.

No master clock output in RPi

According to the Broadcom BCM2835 datasheet (pp. 119-120),

The PCM audio interface has 4 interface signals:
PCM_CLK – bit clock.
PCM_FS – frame sync signal.
PCM_DIN  – serial data input.
PCM_DOUT – serial data output.

…

In clock master mode (CLKM=0), the PCM_CLK is an output and is driven from the PCM_MCLK clock input.

In clock slave mode (CLKM=1), the PCM_CLK is an input, supplied by some external clock source.

This lack of master clock output can also be seen in the P5 header of the RP1 [link]:

And Also as indicated from the developers of RP1 DACs [link]

What about the SCLK (MCLK) signal on DAC chip?

The Raspberry Pi (RPi) does not provide such a signal, it outputs just the other I2S signals: LRCK, DATA and BCK, but not a system clock.

…

The PCM1794A works well if the SCLK (MCLK) signal is connected with the BCK signal which is done on the RPi-DAC board via a jumper (SCLK is BCK).

The PCM_MCLK is the master clock and it seems internally generated. There is no other reference to PCM_MCLK in the datasheet. The bit-clock (PCM_CLK) is the reference clock used for I2S.

RPi Jitter numbers?

According to this post [link], there is a single phase jitter data point of -54 dBc/Hz at 100 Hz (for a carrier frequency of 1.411 MHz, which is the sample rate for 44.1KHz/16bit). What does this mean?

Typically one would see phase jitter plots for clocks and typically at the source frequency (e.g. 24.576Mhz, etc). Here is a phase jitter value of the bit-clock. In the case of RPi, this clock is derived from the 19.2MHz and scaled by “fractional clock divider”

I was able to find a phase jitter plot from Audiophileo [link]. There the phase noise of the device is compared against the phase noise of the device with a “jitter simulator” turned on. The carrier frequency is 2.822 MHz, which is the frequency of 44.1KHz/32bit. This frequency corresponds to the bit-clock, so hopefully this is a fair comparison.

The plot below is the plot from Audiophile0 with the phase jitter value of -54 dBc/Hz at 100 Hz superimposed. I followed the same slope as the other curves and extrapolated to 1 Hz. Then I used a jitter calculator to find the RMS jitter [link]. The result is shown below. The jitter value for the RPi is the green dotted line. The pink line represents the added jitter to the Audiophileo native jitter which is shown in the blue line.

WHICH PLATFORM?

The two most popular (and lowest priced) boards are the Rasberry Pi (RPi) and the BeagleBone Black (BBB). Here is a nice comparison of the two boards [link].

Here is my comparison for audio (please comment if you see any inaccuracies).

Parameter	Rasberry Pi	BeagleBone Black	Comments
Native support for 44.1K and family	Yes, through “fractional clock dividers”	No	It remains to be seen how much jitter is introduced by the “fractional clock division” of the RPi
Native Support up to 384KHz	No. On-board clock is 19.2MHz	Yes. On-board clock is 25.576MHz	RPi can support up to 192K material
Support for USB DAC	Yes (LAN9512 chip [link])	Yes (Built-in in the main processor)	USB in the RPi goes through a buil-in HUB and it is shared with the LAN controller within the USB/LAN chip. USB in the BBB is natively supported by the main processor and LAN by a separate chip
External Clock capability	?; likely not	Yes	The master clock in BBB can be provided externally by disabling the on-board audio-freq clock. The Master clock in the RPi seems internally generated
Built-in rechargeable battery operation	No	Yes [link]	Rechargeable Batt operation in BBB would disable the 5V supply to the USB. Thus for USB operation, where the USB adapter takes the power from USB, it must be powered with 5V DC

SUMMARY

I’d say that the current best option for audio is through a USB-I2S device until the clock issues are better understood. The current best option for a computing board is the BBB primarily because it can support (or more likely to support) and external clock board. If you already have RPi/I2S-DAC and are happy with it, that’s what really matter…