AirTunes with Raspberry Pi

Computer Audio System

I'm always interested in the computer based HiFi audio solution, the only reason is that I'm a lazy guy. I'll prefer to store all my audio files on a NAS instead of building a huge CD shelf, save the time from swapping CDs from the CD player, and enjoy the music on the sofa.

One of the solution is to set up a dedicate PC or Mac, connect it to a DAC with USB input. With this kind of approach, you might need to rebuild the power supply system for the PC/Mac, such as a linear power supply, since the factory power of a PC/Mac is usually switching based. The problem is, to provide sufficient power to the PC/Mac from a linear power supply, you'll need a large transformer, regulator block and maybe a pool of capacitors or some decent designs on noise filtering. Except for the power, since USB is usually the output of audio (digital), you'll then need to spend some time to make or find a decent USB DAC for your CAS system. 

Or you can do something similar to me, by modifying an Apple Airport Express, power it up with a relatively smaller power supply, connect the AAE SPDIF output to a DAC, and enjoy the AirTunes (AirPlay with music only) feature on iTunes.

Asynchronous USB Sound Card

Most of the CAS fans are looking for the Async USB Sound Card solution, so that they can send the audio data to the Async USB Sound Card device, and the processor on the Async USB device will regenerate the clock on board independently from the clock generate from the source PC/Mac.

PureAudio DDC 192 is one example of such kind of solution. Its design is based on the XMOS chip, following the USB Audio Class 2.0, which is supported natively on Mac OSX and Linux today. (For Windows, you will need to install the drivers)

By connecting the PC/Mac to the Async USB Sound Card device, we are good to go.

Raspberry Pi

However, I really don't like the overkill solution for using a PC/Mac as the CAS solution. So I stayed with the AAE solution for awhile. But there's a problem for the AAE solution, I always have some concerns regarding the WiFi - Radio Frequency (Although I kept it off in the AAE setting), since it may possibly introduce more noises to the AAE. Now, there might be a potential solution for me -  Raspberry Pi .

RPi is a cheap educational embedded Linux solution at cost less than 26 pounds. It has built-in Ethernet  port, open source Linux support, low power consumption. Such architecture is very similar the AAE, but RPi's WiFi interface is  "optional".

RPi is powered by a 5V/700 mA DC power supply, and for an audiophile, to build a decent power supply for it shouldn't be a difficult problem. and the good thing is, I can modify anything I want on the Linux OS.

AirTunes/AirPlay

The other good news is: since RPi is based on Linux, which means I can compile the "Shairport" (An open source AirTunes implementation ) on it, so that I don't have to move from my existing iTunes audio database to another solution.

 

My plan is to connect the RPi to the Async USB Sound Card, send the audio stream from iTunes to RPi via Shairport, and redirect the audio output from Shairport to the Async USB Audio, and then to my DAC.

After a few trial & error, I found that it is quite easy. And I can successfully "airplay" the music from my iTunes to it.

AAE vs. Raspberry Pi + Async USB

I had a simple listening comparison, even with just a switching power supply, RPi + Async USB solution has slightly better low end (I believe that is contributed by PureAudio DDC 192) and very similar resolution than my current AAE solution (with modified linear power and digital signal processing). Although the difference is small, but note that I haven't touched anything on the power for RPi.

I think the RPi will be a neat and potential solution for me as a replacement for AAE. The next step will be power the RPi up by a linear power supply, and see how much difference can I get.

AES/EBU: Receiver End with Transformer vs. Transformer-less

Environment

• Pulse Transformer: SC947-02
• Cable: Gotham GAC-2 CE
• Receiver End Termination Resistor: 110 Ohm

Receiver End With Transformer

Transformer-less Receiver End

AES/EBU Cable: Gotham GAC-2 CE vs. Canare DA206

Gotham GAC-2 CE

Canare DA206

SPDIF Cable Test - Belden 83264 vs. 89259

Datasheets

Belden 83264

Belden 89259

Results on scope

Belden 83264

Belden 89259

Does La Rosita Plugin Really Support Hi-RES AirPlay?

La Rosita By DB System

Similar to Micromega, La Rosita is another well known Airport Express based system with power supply and accurate clocking improvements.

Recently, the maker of La Rosita - DB System, has announced a plug-in software - Rosita Plugin , which were claimed having the ability to support AirPlay Hi-RES audio stream to the AAE devices up to 24/192k and attracted my attention.

Without doubt, the performance of La Rosita is well recognized by the users all over the world. This article is not intended to criticize their innovation, but would like to understand the possible approach in their plugin software in order to support Hi-RES AirPlay.

The Clue - Test de La Rosita Plugin

La Rosita demonstrates their plugin via YouTube - Test de La Rosita Plugin.

In the video, they use the Activity Monitor on the Mac OSX to show the Network data rate is much higher (nearly twice) while using Rosita Plugin for AirPlaying to AAE than using native iTunes AirPlay as an evidence of Rosita Plugin's ability in supporting Hi-RES AirPlay.

In the following picture, we can see that the network data rate is at around 113kBytes/sec while using iTunes.

With Rosita Plugin, the network data rate is increased to 198kBytes/sec, which is nearly twice.

However, it didn't convince me that Rosita Plugin does have the ability for transmitting Hi-RES audio stream via AirPlay. 

AirPlaying Uncompressed ALAC

In my previous article - Possibility for Airplay/AirTunes to Airport Express with Hi-Res Audio, I did some experiments in order to find out the possibly for AirPlaying Hi-RES audio stream directly to the AAE, and one of the tool I used is JustePort, written by Jon Lech Johansen.

There are two ways to feed an audio file in to JustePort for AirPlaying, feeding an ALAC (Apple Lossless) file encoded in the M4A file, or decoding an audio file in some other formats in to PCM WAVE and feed in to JustePort by standard input. The following is the README file in JustePort source code:

Usage:

* JustePort.exe input ipaddress [volume]

volume range is -144 to 0, default: -30.00

Example 1 - streaming a MPEG4 Apple Lossless file:

JustePort.exe ~/Music/song1.m4a 10.0.1.1

Example 2 - streaming a MPEG4 AAC file:

faad -q -w -f 2 ~/Music/song2.m4a | JustePort.exe - 10.0.1.1

Example 3 - streaming an Ogg Vorbis file:

oggdec -Q -R -o - ~/Music/song3.ogg | JustePort.exe - 10.0.1.1

If we look in to the source code of JustePort,

if( Args[ 0 ].Equals( "-" ) )
{
    BinaryReader br;
    br = new BinaryReader( Console.OpenStandardInput() );
    while( true )
    {
        byte [] raw = br.ReadBytes( 4096 * 2 * 2 );
        if( raw.Length == 0 )
            break;
        byte [] alac = EncodeALAC( raw );
        at.SendSample( alac, 0, alac.Length );  
    }
}

We will find that, when we are using "-" to feed an audio stream in PCM format in to JustePort, it actually take the stream and then encode it in to ALAC format before transmitting to the AAE.

And if we look into more detail of the EncodeALAC() function:

private static byte [] EncodeALAC( byte [] buffer )
{
 
    BitBuffer bitbuf = new BitBuffer( (4096 * 2 * 2) + 3 ); 

    bitbuf.WriteBits(1, 3);  // channels -- 0 mono, 1 stereo

    bitbuf.WriteBits(0, 4);  // unknown

    bitbuf.WriteBits(0, 12); // unknown

    bitbuf.WriteBits(0, 1);  // 'has size' flag

    bitbuf.WriteBits(0, 2);  // unknown

    bitbuf.WriteBits(1, 1);  // 'no compression' flag

    for( int i = 0; i < buffer.Length; i += 2 )
    {

        // endian swap 16 bit samples

        bitbuf.WriteBits(buffer[i+1], 8);

        bitbuf.WriteBits(buffer[i], 8);

    }

    return bitbuf.Buffer;

}

Note the bitbuf.WriteBits(1,1), if this bit (so called Escape Flag in ALAC format) is set to 1, which means the audio channel data of the ALAC stream is "Uncompressed".

This means, if we decode an ALAC file and feed the output in to JustePort, it will re-encode the audio data in to ALAC format and send to AAE without compression.

Data Rate Verification for JustePort

I did some more testing by feeding the same ALAC file in to JustePort in three different ways:

Case 1: Feeding ALAC file as an argument of JustePort (Will be sent to AAE as compressed ALAC stream)

$ mono JustePort.exe Koln-16-44.m4a 10.100.1.61 -10
JackStatus: connected
JackType: analog

Case 2: Convert the same ALAC into WAV, and feed the WAV file into STDIN of JustePort (Will be sent to AAE as uncompressed ALAC stream)

$ cat Koln-16-44.wav | mono JustePort.exe - 10.100.1.61 -10
JackStatus: connected
JackType: analog

Case 3: Play the same ALAC file in iTunes. (Will be sent to AAE as compressed ALAC)

We can see that the data rates in Case 2 is much higher (uncompressed) while in Case 1 and 3 are quite similar. This is a very similar result with Rosita Plugin.

We Might Need More Evidence

I don't dare to say that Rosita Plugin is unable to support Hi-RES Airplay. But obviously with such a simple test by comparing the differences in data rate, it is not sufficient to convince people that Rosita Plugin can really Airplay the Hi-RES audio files to the AAE. With the differences in data rate, it can only prove that Rosita Plugin has the ability to send the uncompressed audio stream to AAE, it doesn't provide the evidence for Hi-RES Airplaying ability.

In above tests, we can see that sending an uncompressed 16/44.1k ALAC stream to AAE will create a data rate at 176kBytes/sec. If Rosita Plugin can really Airplay an 24/192k audio file to AAE natively, let's do some math:

Bit-depth: 16 --> 24, we need to send 8 more bits per audio sample, which is 1.5X in data rate.

Sampling-Rate: 44100 Hz --> 192000 Hz, we need to send 4X samples in the same period.

The total variation in data rate must at least 6X (4 x 1.5) higher, which implies that we may expect to see 176kBytes/sec x 6 = 1056kBytes/sec if Rosita Plugin can really do it at 24/192k.

I'll be very happy to see if anyone who owns the La Rosita and Rosita Plugin can share with the evidence while playing a 24/192k audio file.