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.