Get Your Guitar Amp Volume Under Control

Problem

I've been enjoyed playing electric guitars at home for a long time.

Based on the experience I learned in the Hi-Fi audio, I realized that I become quite picky on the tonal performance, not only in the music reproduction (Hi-Fi) and also in the music production (instruments) as well.

A few years ago, I got a Mesa Boogie Express 5:50 guitar tube amp as one of my guitar amp at home.
It is always a pleasant experience in playing with it, but I was always worrying about my neighbor might kick my doors if I crank the volume up.

This is a very general problem on the guitar tube amp.
Except for those guitar amp models with an OUTPUT knob such as Mark V or LoneStar, for models with MASTER volume only, it is a headache to reach the tonal headroom while also maintaining the volume within an acceptable level.

The project here is how I manage to solved the problem by creating a volumne adaptor for my guitar amp.

A Study Before Actions

I did a little research on the guitar amp schematic on the Internet.
Here's what I found for Mesa Boogie LoneStar:

We can see that on the amp with OUTPUT design, an OUTPUT potentiometer (1M Ohm Type A in the above case) is installed in the signal path after the RETURN connection point.

I then take a look at the schematic which I can find on the Internet for Express 5:50.

The FX Loop circuit of Express 5:50 didn't have such POT for controlling the OUTPUT volume.
Hence I came out with an idea: why not installing a POT in between the FX Loop to introduce the OUTPUT control?
Here some requirements for this approach I realized:
1. I don't want to do any physical modification on the guitar amp.
2. To make the OUTPUT volume adjustable, a POT is required. But I don't want to drill a hole on the chassis of my guitar amp.
3. The solution must not block the FX Loop, since I need to use the SEND/RETURN to send the signal to other sound processors in my setup.
4. No external power is required.
5. Keep the dimension as small as possbile.

Solution

I decide to make an "adopter" as the solution.

Material

1. Switchcraft #280 1/4" Mono Phone Jack x 2

Actually we don't need all components, just the main jack assembly will be good enough.

2. Neutrik NRJ6HH-AV 1/4" Socket x 2

The sockets here are intended for create the EXTENDED SEND/RETURN connections. Note the structure of the socket, when you plug in the phone jack, the connection pins on the left will be isolated to the connection pins on the right. The reason for using this type of socket is to make it possible when there is no cable connected to the EXTENDED SEND/RETURN, the signal will be kept in the adopter, and when FX Loop is required, I will still be able to send the signal to other processors by EXTENDED SEND socket and get the signal back by connecting the cable from the processors to the EXTENDED RETURN socket.

3. CTS 1M Ohm Type A Potentiometer x 1

Note the potentiometer shoud be installed AFTER EXTENDED RETURN socket. The reason is, if the FX Loop is required, we can always use the existing MASTER pot to control the signal level. But when the signal retured, we will need to control the level by OUTPUT pot here.

4. A knob for the potentiometer

5. An Aluminum Enclosure with dimension approx. W 50 mm x L 50 mm x D 32 mm
For sure we need to drill holes, so be careful on measurement, keep the error as small as possible.

6. 22 AWG cables for connections

Construction

Here are some pictures for the construction.

Installation

To use it, just plug it in the SEND/RETURN socket on the back of Express 5:50.

And then adjust the original MASTER knob on the amp and the OUTPUT knob on the adopter to find the balance.

The best way to do this, is to connect a cable from the EXTENDED SEND on the adopter to your sound processor INPUT, and adjust the MASTER to make sure the signal level is high enough for the processor input. And then connect a cable from processor OUTPUT back to the EXTENDED RETURN on the adopter, and then adjust the OUTPUT potentiometer on the adopter to get the reasonable volume.

The best thing is, if you don't like, you can always remove it from your amp at anytime.

Cubieboard + Shairport + USB Audio

RPi Replacement

I've previously mentioned a way to use Raspberry Pi with Shairport for supporting AirTunes, and redirect the output to USB audio device. However, due to the BUGGY USB host driver of RPi, the USB packet loss problem (which causes clicks/pops) remains until today. Finally I lose my patience and start looking for a replacement, and found the replacement solution - Cubieboard.

Improvements

Here are the improvements after replacing RPi with Cubieboard:

• No more clicks/pops
• Rapid response to AirTunes
• The same sound quality

So, if you lose patience for RPi like me, I'll suggest you to give Cubieboard a try.

Respberry Pi with Shairport and USB Audio

Foreword

In previous article - AirTunes with Raspberry Pi, I've mentioned a way to use Raspberry Pi with Shairport for supporting AirTunes. Although there're quite a few articles on the Internet providing the guide to install Shairport on RPi, but I couldn't find a good doc mentioning how to use Shairport on Rpi with USB Audio. In this article, I'll try to explain how to intall Shairport and redirect the output to USB Audio.

Install Raspbian "Wheezy"

If you got a RPi in hand, the first thing to do is to download an OS image, and then load it on to the SD card. 

The official Raspbian "Wheezy" image is based on Debian, you can download it from here. You can choose any other OS package works on RPi, but it is better to star from the official OS package if you are new to RPi or even new to Linux based OS.

There are a few ways to make the SD card, since I'm using Mac OS X, I'll only explain how to write the image to an SD card by "dd" UNIX based utility.

Firstly, we need to open a terminal window, you can find a terminal application in /Applications/Utilities/Terminal. Since writing a image to SD card requires "root" permission, you'll need to "su"as root.

mac:~ user$ sudo -s
Password:
bash-3.2#

Insert the SD card in to a Mac. Since the Mac OS X will automatically "mount" the SD card to the system, and we can NOT write the image to a "mounted" disk, we have to "umount" it before writing the OS image to it.

bash-3.2# mount
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk3s1 on /Volumes/NO NAME (msdos, local, nodev, nosuid, noowners)
bash-3.2#

As you can see, /dev/disk3 is the inserted SD card, and its first partition /dev/disk3s1 is mounted by Mac OS X automatically. Now we need to umount it.

bash-3.2# umount /dev/disk3s1
bash-3.2#

Also, we need to decompress the downloaded image:

bash-3.2# unzip 2012-12-16-wheezy-raspbian.zip
Archive: 2012-12-16-wheezy-raspbian.zip
inflating: 2012-12-16-wheezy-raspbian.img
bash-3.2#

Now, we are ready to write the image to SD card:

bash-3.2# dd if=2012-12-16-wheezy-raspbian.img of=/dev/disk3

It might take 20 minutes to complete, depends on the write speed of your SD card, so get a coffee and wait until it completes.

Once done, you can eject the SD card from your Mac and insert it on RPi, then plug in the power cord for booting up, you can then log in with user "pi" and password "raspberry".

Install Shairport

The following steps for installing the Shairport are mostly taken from here. However, we need to skip a few steps since we are going to use the USB Audio instead of the built-in HDMI or sound card analogue output.

After login, install the "git" utility

# sudo apt-get install git

Then install all other dependencies,

# sudo apt-get install build-essential libssl-dev libcrypt-openssl-rsa-perl libao-dev libio-socket-inet6-perl libwww-perl avahi-utils pkg-config
# sudo aptitude install libmodule-build-perl
# sudo git clone https://github.com/njh/perl-net-sdp.git perl-net-sdp
# cd perl-net-sdp
# perl Build.PL
#./Build
#./Build test
# sudo ./Build install

Get Shairport, then compile and install it

# Sudo git clone https://github.com/hendrikw82/shairport.git shairport
# cd shairport
# sudo make install

We'll need the Shairport running at RPi boot up,

# sudo cp shairport.init.sample /etc/init.d/shairport
# sudo insserv shairport

 Identify USB Audio Device

The audio devices on Linux is based on ALSA (Advanced Linux Sound Architecture), before redirecting the audio output through the USB audio device, we need to verify if our USB audio device can be recognized by ALSA.

pi@raspberrypi:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: Audio [PureAudio  USB HD Audio], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
pi@raspberrypi:~$

In above, the built-in sound card (BCM2835) is recognized as card 0/device0, and my PureAudio DDC 192 is recognized as card1/device0.

Before we redirect the output of Shairport, we need to make sure our USB audio device is not muted by the ALSA by default. If so, it must be unmuted first.

pi@raspberrypi:~$ sudo alsamixer

By pressing F6, we selected the sound card 1, i. e. our USB Audio device.

As we can see, there are two sub-devices under card 1, and one of these sub-devices is muted. (Pay attention to the "MM"). By using the UP/DOWN/LEFT/RIGHT keys, we can move the cursor to the sub-device, and by pressing "M" key, we toggled it to "unmute" state. ("MM" will become "00").

Once done, press ESC to exit and save the settings.

Redirect The Output of Shairport 

In previous sections, while we installing the Shairport, we have copied a sample startup script in to /etc/init.d, so that the Shairport will be started at boot time. However, since our goal is to play the audio via the USB audio device instead of the built-in sound card, we will need to modify the startup script to redirect Shairport's output to our USB audio device. You'll need a Text-Editor to complete the job. either vi, nano or joe will do the job. If you are not familiar with vi, you will need to install nano or joe. Here's an example for installing joe and edit the shairport startup script by joe.

pi@raspberrypi:~$ sudo apt-get install joe

Reading package lists... Done
Building dependency tree

Reading state information... Done

joe is already the newest version.

The following packages were automatically installed and are no longer required:
gstreamer0.10-pulseaudio libaudiofile1 libavformat53 libfaad2 libfftw3-3 libmms0 libmpcdec6 libmpdclient2 libshout3 libsystemd-daemon0
libwavpack1 libwebrtc-audio-processing-0 pulseaudio-utils rtkit

Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 30 not upgraded.

pi@raspberrypi:~$

pi@raspberrypi:~$ sudo joe /etc/init.d/shairport

Here's an example of modified startup script.

#!/bin/bash
#
# This starts and stops shairport
#
### BEGIN INIT INFO
# Provides: shairport
# Required-Start: $network
# Required-Stop:
# Short-Description: shairport - Airtunes emulator!
# Description: Airtunes emulator!
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO


# Source function library.

. /lib/lsb/init-functions

SPEAKER="MyShairport"
NAME=ShairPort
AODEV="plughw:1,0"
DAEMON="/usr/local/bin/shairport.pl"
PIDFILE=/var/run/$NAME.pid

#DAEMON_ARGS="-w $PIDFILE -a $NAME"
DAEMON_ARGS="-w $PIDFILE -a $SPEAKER --ao_devicename=$AODEV"

[ -x $binary ] || exit 0

RETVAL=0

start() {
    echo -n "Starting shairport: "
    start-stop-daemon --start --quiet --pidfile "$PIDFILE" \
                      --exec "$DAEMON" -b --oknodo -- $DAEMON_ARGS
    # Unmoute alsamixer
    amixer set -c 1 "PureAudio  Clock Selector" 127 unmute
    log_end_msg $?

At first, we can defined a "speaker name" for Shairport, so that you can identify it in iTunes.

SPEAKER=MyShairport

Secondly, we need to define an audio output device for redirecting the Shairport's output to the device. Since our USB audio device was identify as card 1/device 0 in previous section, we defined the AODEV as following:

AODEV="plughw:1,0"

Then we need to comment the original DEMON_ARGS by putting a "#" in front of the line, and recreated a new line to replace it.

#DAEMON_ARGS="-w $PIDFILE -a $NAME"
DAEMON_ARGS="-w $PIDFILE -a $SPEAKER --ao_devicename=$AODEV"

In the "start()" section, we need to add a line to "unmute" our USB audio device automatically at boot time instead of using alsamixer to toggle the setting everytime.

# Unmute alsamixer
amixer set -c 1 "PureAudio  Clock Selector" 127 unmute

Once completed, save the startup script, and then reboot the RPi. You should be able to airplay the music in your iTunes via the "MyShairport".

pi@raspberrypi:~/shairport$ sudo reboot

Troubleshooting

If you can see the "MyShairport" in your iTune, but cannot hear anything, try to log on RPi, and use alsamixer to check if it is muted again.

Caveat

According to the hardware architecture of Raspberry Pi, the network interface is connected to the processor via USB as well. Hence the efficiency of USB host driver will be critical for using USB audio device. Unfortunately, the USB host driver of RPi is not so efficient, even buggy. Don't be surprise if you found some unexpected clicks or pops while playing audio files through Shairport.

I've tested playing a WAV file on RPi locally with USB audio device, even without any network traffic, I'll still get some clicks and pops.

However, I do have successfully airplayed audio on RPi without any clicks/pops by using another USB audio device. The difference in between is the PCM output format of USB, the one without clicks/pops transferred the PCM to USB audio device using 24 bit on 3 bytes (24_3LE) for each audio sample, and the one with clicks/pops used 24 bit on 4 bytes (32_LE). It seems that by increasing 25% precent in the amount of data on the USB bus, it is more easier to get the clicks/pops. Hope the RPi foundation and BroadCom will come out with a solution for the USB host driver soon, or else, we may need to look for another solution.

On the other hand, with RPi's simplified hardware architecture with Async USB audio device, it sounds really beautiful and accurate. To me, it might be a prefect solution if RPi can get the USB issues resolved. I'll pay a little bit more patient for RPi for awhile unless I found another neat solution.

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.

Possibility for Airplay/AirTunes to Airport Express with Hi-Res Audio

I'm quite happy with my modified Airport Express currently since I can use my iPhone/iPad/iMac streaming audio files to Airport Express on demand.

However, the only drawback is: AE only supports 16-bit 44.1 kHz sampling rate.

Even though, I still can successfully play the 24-bit 96 kHz on my iTunes, and "airplays" onto AE, and AE will send the stream to my DAC via SPDIF. In this case, the DAC shows that the signal is a 16-bit / 44.1 kHz one.

This implies that there's a device along the path which did the down sampling from 24/96 to 16/44.1 for sure. But the question is: is the down-sampling done by iTunes or the AE itself?

I try to find the answer through the Internet, however there's no firm answer.

I decided to find the answer by myself, and I found this:

JustePort

Jon Lech Johansen has shown us a way to send an audio stream to the AE.
I then compile Jon's code on my desktop, and send the following two files in Apple lossless format by his JustePort to my AE.

Streaming-Test$ mono JustePort.exe Koln-16-44.m4a 10.100.1.6

JackStatus: connected

JackType: analog

^C
Streaming-Test$ 



Streaming-Test$ mono JustePort.exe Koln-24-96.m4a 10.100.1.6JackStatus: connected

JackType: analog
^C
Streaming-Test$

With the 16/44.1 file, the AE works well as usual, but with 24/96 one, AE couldn't successfully decode the audio stream, but is still passing the signal to my DAC, and it sounds just like a bunch of digital noise.
Through this test, I confirm that AE itself can only handle 16/44.1. If you are trying to send a 24/96 audio stream to it, it just can't recognize it, and is not able to decode the stream.
Obviously, for audio file above 16/44.1, the down-sampling takes place in iTunes and the audio stream gets converted into 16/44.1 before it leaving the iTunes.
Findings Now I have two findings through this simple test: 1. If I can make an Airplay streaming receiver similar to AE, however supporting higher sampling rate, then I will be able to play 24/96 audio files with it.
2. Down-sampling is done by iTunes for sure, hence, even if I can make an AE-like but is a 24/96 capable receiver, I also need to make sure that iTune will send an 24/96 audio stream to it without down-sampling.
iTunes with Airport Express The following is the RTSP ANNOUNCE message sent by iTunes

ANNOUNCE rtsp://10.0.1.101/3172942895 
RTSP/1.0
CSeq: 1
Content-Type: application/sdp
Content-Length: 567
User-Agent: iTunes/4.6 (Windows; N)
Client-Instance: 9FF35780A8BC8D2B
Apple-Challenge: 09KF45soMYmvj6dpsUGiIg

v=0
o=iTunes 3172942895 0 IN IP4 10.0.1.101
s=iTunesc=IN IP4 10.0.1.103
t=0 0
m=audio 0 RTP/AVP 96
a=rtpmap:96 AppleLossless
a=fmtp:96 4096 0 16 40 10 14 2 255 0 0 44100
a=rsaaeskey:5QYIqmdZGTONY5SHjEJrqAhaa0W9wzDC5i6q221mdGZJ5ubO6Kg
yhC6U83wpY87TFdPRdfPQl2kVC7+Uefmx1bXdIUo07ZcJsqMbgtje4w2JQw0b
Uw2BlzNPmVGQOxfdpGc3LXZzNE0jI1D4conUEiW6rrzikXBhk7Y/i2naw13ayy
xaSwtkiJ0ltBQGYGErbV2tx43QSNj7O0JIG9GrF2GZZ6/UHo4VH+ZXgQ4NZvP/
QXPCsLutZsvusFDzIEq7TN1fveINOiwrzlN+bckEixvhXlvoQTWE2tjbmQYhMvO
FIly5gNbZiXi0l5AdolX4jDC2vndFHqWDks/3sPikNga=aesiv:zcZmAZtqh7uGcEwPXk0QeA

RTSP/1.0 200 OK
CSeq: 1
Apple-Response: u+msU8Cc7KBrVPjI/Ir8fOL8+C5D3Jsw1+acaW3MNTndrTQAeb/a
5m10UVBX6wb/DYQGY+b28ksSwBjN0nFOk4Y2cODEf83FAh7B
mkLpmpkpplp7zVXQ+Z9DcB6gC60ZsS3t98aoR7tSzVLKZNgi2X2sC+vGsz
utQxX03HK008VjcdngHv3g1p2knoETd07T6eVfZCmPqp6Ga7Dj8VIIj/GEP3
AjjDx3lJnQBXUDmxM484YXLXZjWFXCiY8GJt6whjf7/2c3rIoT3Z7PQpEvPmM
1MXU9cv4NL59Y/q0OAVQ38foOz7eGAhfvjOsCnHU25aik7/7ToIYt1tyVtap/kA
Audio-Jack-Status: connected; type=analog

We can see that iTunes announce the parameters in a=fmtp: section, and possibly specifying the followings:

Codec = 96 (Apple lossless)
Frames-per-packet = 4096 (ALAC default setting)
Compatible Version = 0 (must be 0)
Sample-Size = 16 (so called bit-depth, max = 32)
pb = 40 (currently unused parameter, should be set to 40)
kb = 10 (currently unused parameter, should be set to 10)
mb = 14 (currently unused parameter, should be set to 14)
Number of Channels = 2 (i.e. stereo)
Max Run = 255 (currently unused parameter, should be set to 255)
Max Frame Bytes = 0 (The max size of an ALAC packet within the encoded stream, 0 = unknown)
Average Bit Rate = 0 (Average Bit Rate in bps, 0 = unknown)
Sampling-Rate = 44100

Hint: the above info were discovered from ALAC code.

A Simple Test

As we can see that the Sample Size (16 bits) and Sampling Rate (44100 Hz) of the audio stream is ANNOUNCED in the RSTP ANNOUNCE message by the Session Description Protocol (SDP), I'm wondering what will happen if I set those parameters to 24/96k instead?

I then modify the JustePort source codes, and set those values to 24/96k, recompile and play a 24/96k ALAC file. At first, AE received the stream, but couldn't decode it (of course), and produced hiss sound.  And then about half a second, the JustePort reports error, then stream is then terminated. After that, I was no longer able to send any further audio stream to the AE, since it just refused for any connection. (I guess AE was crashed at this stage, even it still responded to PING.)

I also played a 16/44.1k file with the modified 24/96k JustePort, although the AE cannot successfully decode the stream, however it didn't crash. After that, I can still play a 16/44.1k file with the normal version of JustePort.

To me, this small test proved a few things:

1. SDP parameters determine how does the AE decode the audio stream. Even if 24/96k is supported on  AE, you might need to change the SDP parameters as well.
2. SDP parameters must match the ALAC format.

Conclusion for iTunes+AE 

1. iTunes down-sampling the ALAC file to 16/44.1 if it is originally at higher sampling rate.
2. iTunes encapsulates and sends the ALAC stream to AE directly.
3. Decoding is done on the AE, and AE only supports 16/44.1.

iTunes with AppleTV (2nd Gen)

So, how about the Apple TV?

It is known that Apple TV will up/down-sample everything to 16/48k, but my questions on mind are:

1. Where does the up/down-sampling taking place? Done by iTunes? Or the AppleTV itself?

2. If the up/down-sampling is done by iTunes, I should be able to see the SDP parameters are set to the same with the audio source file.

3. If the up/down-sampling is done by AppleTV, then at what sampling-size/rate does the iTunes send?

Recalling that SDP parameters should match the audio file, I did the following test:

• Play a 16/44.1k and a 24/96k file with iTune and sending to Apple TV
• Perform a packet capture with Wireshark

The followings are the captured ROAP/RSTP ANNOUNCE packets for 16/44.1k and 24/96k respectively:

• 16/44.1k file playback:

No.     Time        Source                Destination           Protocol Length Info
   2789 5.633568    fe80::c62c:3ff:fe12:cdc0 fe80::5a55:caff:fe4e:bd6b TCP      732    54702 > 49152 [PSH, ACK] Seq=720 Ack=400 Win=65688 Len=646 TSval=778938126 TSecr=839386389


Frame 2789: 732 bytes on wire (5856 bits), 732 bytes captured (5856 bits)
Ethernet II, Src: Apple_12:cd:c0 (c4:2c:03:12:cd:c0), Dst: Apple_4e:bd:6b (58:55:ca:4e:bd:6b)
Internet Protocol Version 6, Src: fe80::c62c:3ff:fe12:cdc0 (fe80::c62c:3ff:fe12:cdc0), Dst: fe80::5a55:caff:fe4e:bd6b (fe80::5a55:caff:fe4e:bd6b)
Transmission Control Protocol, Src Port: 54702 (54702), Dst Port: 49152 (49152), Seq: 720, Ack: 400, Len: 646
    Source port: 54702 (54702)
    Destination port: 49152 (49152)
    [Stream index: 41]
    Sequence number: 720    (relative sequence number)
    [Next sequence number: 1366    (relative sequence number)]
    Acknowledgement number: 400    (relative ack number)
    Header length: 32 bytes
    Flags: 0x18 (PSH, ACK)
    Window size value: 32844
    [Calculated window size: 65688]
    [Window size scaling factor: 2]
    Checksum: 0x100c [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    Options: (12 bytes)
        No-Operation (NOP)
        No-Operation (NOP)
        Timestamps: TSval 778938126, TSecr 839386389
            Kind: Timestamp (8)
            Length: 10
            Timestamp value: 778938126
            Timestamp echo reply: 839386389
    [SEQ/ACK analysis]
        [Bytes in flight: 646]
Data (646 bytes)

0000  41 4e 4e 4f 55 4e 43 45 20 72 74 73 70 3a 2f 2f   ANNOUNCE rtsp://
0010  66 65 38 30 3a 3a 63 36 32 63 3a 33 66 66 3a 66   fe80::c62c:3ff:f
0020  65 31 32 3a 63 64 63 30 2f 33 34 30 35 31 31 35   e12:cdc0/3405115
0030  33 38 38 20 52 54 53 50 2f 31 2e 30 0d 0a 43 53   388 RTSP/1.0..CS
0040  65 71 3a 20 33 0d 0a 43 6f 6e 74 65 6e 74 2d 54   eq: 3..Content-T
0050  79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e   ype: application
0060  2f 73 64 70 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65   /sdp..Content-Le
0070  6e 67 74 68 3a 20 33 34 38 0d 0a 55 73 65 72 2d   ngth: 348..User-
0080  41 67 65 6e 74 3a 20 69 54 75 6e 65 73 2f 31 30   Agent: iTunes/10
0090  2e 35 2e 31 20 28 4d 61 63 69 6e 74 6f 73 68 3b   .5.1 (Macintosh;
00a0  20 49 6e 74 65 6c 20 4d 61 63 20 4f 53 20 58 20    Intel Mac OS X 
00b0  31 30 2e 36 2e 38 29 20 41 70 70 6c 65 57 65 62   10.6.8) AppleWeb
00c0  4b 69 74 2f 35 33 34 2e 35 31 2e 32 32 0d 0a 43   Kit/534.51.22..C
00d0  6c 69 65 6e 74 2d 49 6e 73 74 61 6e 63 65 3a 20   lient-Instance: 
00e0  42 38 41 45 45 41 45 42 45 35 39 37 44 42 44 37   B8AEEAEBE597DBD7
00f0  0d 0a 44 41 43 50 2d 49 44 3a 20 42 38 41 45 45   ..DACP-ID: B8AEE
0100  41 45 42 45 35 39 37 44 42 44 37 0d 0a 41 63 74   AEBE597DBD7..Act
0110  69 76 65 2d 52 65 6d 6f 74 65 3a 20 34 31 38 38   ive-Remote: 4188
0120  32 32 30 30 38 30 0d 0a 0d 0a 76 3d 30 0d 0a 6f   220080....v=0..o
0130  3d 69 54 75 6e 65 73 20 33 34 30 35 31 31 35 33   =iTunes 34051153
0140  38 38 20 30 20 49 4e 20 49 50 34 20 66 65 38 30   88 0 IN IP4 fe80
0150  3a 3a 63 36 32 63 3a 33 66 66 3a 66 65 31 32 3a   ::c62c:3ff:fe12:
0160  63 64 63 30 0d 0a 73 3d 69 54 75 6e 65 73 0d 0a   cdc0..s=iTunes..
0170  63 3d 49 4e 20 49 50 34 20 66 65 38 30 3a 3a 35   c=IN IP4 fe80::5
0180  61 35 35 3a 63 61 66 66 3a 66 65 34 65 3a 62 64   a55:caff:fe4e:bd
0190  36 62 0d 0a 74 3d 30 20 30 0d 0a 6d 3d 61 75 64   6b..t=0 0..m=aud
01a0  69 6f 20 30 20 52 54 50 2f 41 56 50 20 39 36 0d   io 0 RTP/AVP 96.
01b0  0a 61 3d 72 74 70 6d 61 70 3a 39 36 20 41 70 70   .a=rtpmap:96 App
01c0  6c 65 4c 6f 73 73 6c 65 73 73 0d 0a 61 3d 66 6d   leLossless..a=fm
01d0  74 70 3a 39 36 20 33 35 32 20 30 20 31 36 20 34   tp:96 352 0 16 4
01e0  30 20 31 30 20 31 34 20 32 20 32 35 35 20 30 20   0 10 14 2 255 0 
01f0  30 20 34 34 31 30 30 0d 0a 61 3d 66 70 61 65 73   0 44100..a=fpaes
0200  6b 65 79 3a 52 6c 42 4d 57 51 45 43 41 51 41 41   key:RlBMWQECAQAA
0210  41 41 41 38 41 41 41 41 41 46 6e 4d 53 77 79 48   AAA8AAAAAFnMSwyH
0220  2b 50 47 41 48 4d 59 6f 56 59 50 31 6b 7a 55 41   +PGAHMYoVYP1kzUA
0230  41 41 41 51 31 78 58 4c 56 72 57 55 36 4c 76 77   AAAQ1xXLVrWU6Lvw
0240  36 30 37 62 78 64 73 52 72 61 48 5a 52 50 54 62   607bxdsRraHZRPTb
0250  33 51 35 2f 50 34 65 63 48 7a 7a 43 32 75 68 39   3Q5/P4ecHzzC2uh9
0260  6e 71 42 79 0d 0a 61 3d 61 65 73 69 76 3a 47 79   nqBy..a=aesiv:Gy
0270  62 52 45 61 42 6a 39 71 6f 57 70 71 46 6c 46 55   bREaBj9qoWpqFlFU
0280  48 66 55 41 0d 0a                                 HfUA..
    Data: 414e4e4f554e434520727473703a2f2f666538303a3a6336...
    [Length: 646]

24/96k file playback:

No.     Time        Source                Destination           Protocol Length Info
   3635 7.948851    fe80::c62c:3ff:fe12:cdc0 fe80::5a55:caff:fe4e:bd6b TCP      732    56361 > 49152 [PSH, ACK] Seq=720 Ack=400 Win=65688 Len=646 TSval=778943908 TSecr=839964791

Frame 3635: 732 bytes on wire (5856 bits), 732 bytes captured (5856 bits)
    Arrival Time: Nov 26, 2011 01:32:47.458693000 CST
    Epoch Time: 1322242367.458693000 seconds
    [Time delta from previous captured frame: 0.000465000 seconds]
    [Time delta from previous displayed frame: 0.000465000 seconds]
    [Time since reference or first frame: 7.948851000 seconds]
    Frame Number: 3635
    Frame Length: 732 bytes (5856 bits)
    Capture Length: 732 bytes (5856 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ipv6:tcp:data]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: Apple_12:cd:c0 (c4:2c:03:12:cd:c0), Dst: Apple_4e:bd:6b (58:55:ca:4e:bd:6b)
    Destination: Apple_4e:bd:6b (58:55:ca:4e:bd:6b)
        Address: Apple_4e:bd:6b (58:55:ca:4e:bd:6b)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Apple_12:cd:c0 (c4:2c:03:12:cd:c0)
        Address: Apple_12:cd:c0 (c4:2c:03:12:cd:c0)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::c62c:3ff:fe12:cdc0 (fe80::c62c:3ff:fe12:cdc0), Dst: fe80::5a55:caff:fe4e:bd6b (fe80::5a55:caff:fe4e:bd6b)
    0110 .... = Version: 6
        [0110 .... = This field makes the filter "ip.version == 6" possible: 6]
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
        .... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)
        .... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set
        .... .... ...0 .... .... .... .... .... = ECN-CE: Not set
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 678
    Next header: TCP (0x06)
    Hop limit: 2
    Source: fe80::c62c:3ff:fe12:cdc0 (fe80::c62c:3ff:fe12:cdc0)
    [Source SA MAC: Apple_12:cd:c0 (c4:2c:03:12:cd:c0)]
    Destination: fe80::5a55:caff:fe4e:bd6b (fe80::5a55:caff:fe4e:bd6b)
    [Destination SA MAC: Apple_4e:bd:6b (58:55:ca:4e:bd:6b)]
Transmission Control Protocol, Src Port: 56361 (56361), Dst Port: 49152 (49152), Seq: 720, Ack: 400, Len: 646
    Source port: 56361 (56361)
    Destination port: 49152 (49152)
    [Stream index: 27]
    Sequence number: 720    (relative sequence number)
    [Next sequence number: 1366    (relative sequence number)]
    Acknowledgement number: 400    (relative ack number)
    Header length: 32 bytes
    Flags: 0x18 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgement: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
    Window size value: 32844
    [Calculated window size: 65688]
    [Window size scaling factor: 2]
    Checksum: 0xc7a9 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    Options: (12 bytes)
        No-Operation (NOP)
        No-Operation (NOP)
        Timestamps: TSval 778943908, TSecr 839964791
            Kind: Timestamp (8)
            Length: 10
            Timestamp value: 778943908
            Timestamp echo reply: 839964791
    [SEQ/ACK analysis]
        [Bytes in flight: 646]
Data (646 bytes)

0000  41 4e 4e 4f 55 4e 43 45 20 72 74 73 70 3a 2f 2f   ANNOUNCE rtsp://
0010  66 65 38 30 3a 3a 63 36 32 63 3a 33 66 66 3a 66   fe80::c62c:3ff:f
0020  65 31 32 3a 63 64 63 30 2f 33 34 30 35 31 31 35   e12:cdc0/3405115
0030  39 36 37 20 52 54 53 50 2f 31 2e 30 0d 0a 43 53   967 RTSP/1.0..CS
0040  65 71 3a 20 33 0d 0a 43 6f 6e 74 65 6e 74 2d 54   eq: 3..Content-T
0050  79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e   ype: application
0060  2f 73 64 70 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65   /sdp..Content-Le
0070  6e 67 74 68 3a 20 33 34 38 0d 0a 55 73 65 72 2d   ngth: 348..User-
0080  41 67 65 6e 74 3a 20 69 54 75 6e 65 73 2f 31 30   Agent: iTunes/10
0090  2e 35 2e 31 20 28 4d 61 63 69 6e 74 6f 73 68 3b   .5.1 (Macintosh;
00a0  20 49 6e 74 65 6c 20 4d 61 63 20 4f 53 20 58 20    Intel Mac OS X 
00b0  31 30 2e 36 2e 38 29 20 41 70 70 6c 65 57 65 62   10.6.8) AppleWeb
00c0  4b 69 74 2f 35 33 34 2e 35 31 2e 32 32 0d 0a 43   Kit/534.51.22..C
00d0  6c 69 65 6e 74 2d 49 6e 73 74 61 6e 63 65 3a 20   lient-Instance: 
00e0  42 38 41 45 45 41 45 42 45 35 39 37 44 42 44 37   B8AEEAEBE597DBD7
00f0  0d 0a 44 41 43 50 2d 49 44 3a 20 42 38 41 45 45   ..DACP-ID: B8AEE
0100  41 45 42 45 35 39 37 44 42 44 37 0d 0a 41 63 74   AEBE597DBD7..Act
0110  69 76 65 2d 52 65 6d 6f 74 65 3a 20 34 31 38 38   ive-Remote: 4188
0120  32 32 30 30 38 30 0d 0a 0d 0a 76 3d 30 0d 0a 6f   220080....v=0..o
0130  3d 69 54 75 6e 65 73 20 33 34 30 35 31 31 35 39   =iTunes 34051159
0140  36 37 20 30 20 49 4e 20 49 50 34 20 66 65 38 30   67 0 IN IP4 fe80
0150  3a 3a 63 36 32 63 3a 33 66 66 3a 66 65 31 32 3a   ::c62c:3ff:fe12:
0160  63 64 63 30 0d 0a 73 3d 69 54 75 6e 65 73 0d 0a   cdc0..s=iTunes..
0170  63 3d 49 4e 20 49 50 34 20 66 65 38 30 3a 3a 35   c=IN IP4 fe80::5
0180  61 35 35 3a 63 61 66 66 3a 66 65 34 65 3a 62 64   a55:caff:fe4e:bd
0190  36 62 0d 0a 74 3d 30 20 30 0d 0a 6d 3d 61 75 64   6b..t=0 0..m=aud
01a0  69 6f 20 30 20 52 54 50 2f 41 56 50 20 39 36 0d   io 0 RTP/AVP 96.
01b0  0a 61 3d 72 74 70 6d 61 70 3a 39 36 20 41 70 70   .a=rtpmap:96 App
01c0  6c 65 4c 6f 73 73 6c 65 73 73 0d 0a 61 3d 66 6d   leLossless..a=fm
01d0  74 70 3a 39 36 20 33 35 32 20 30 20 31 36 20 34   tp:96 352 0 16 4
01e0  30 20 31 30 20 31 34 20 32 20 32 35 35 20 30 20   0 10 14 2 255 0 
01f0  30 20 34 34 31 30 30 0d 0a 61 3d 66 70 61 65 73   0 44100..a=fpaes
0200  6b 65 79 3a 52 6c 42 4d 57 51 45 43 41 51 41 41   key:RlBMWQECAQAA
0210  41 41 41 38 41 41 41 41 41 46 4a 70 46 65 37 63   AAA8AAAAAFJpFe7c
0220  6d 6c 6f 57 61 59 6b 79 70 34 47 5a 4d 39 67 41   mloWaYkyp4GZM9gA
0230  41 41 41 51 63 59 4b 68 73 64 77 6e 30 72 68 50   AAAQcYKhsdwn0rhP
0240  7a 36 68 34 6c 54 50 46 63 64 73 47 38 6d 79 47   z6h4lTPFcdsG8myG
0250  6a 74 65 52 53 55 72 70 52 79 78 32 73 79 5a 71   jteRSUrpRyx2syZq
0260  4f 4b 7a 36 0d 0a 61 3d 61 65 73 69 76 3a 72 39   OKz6..a=aesiv:r9
0270  54 6a 4b 6a 46 73 37 42 34 57 44 70 41 68 4f 59   TjKjFs7B4WDpAhOY
0280  4b 73 36 67 0d 0a                                 Ks6g..
    Data: 414e4e4f554e434520727473703a2f2f666538303a3a6336...
    [Length: 646]

Did you see that?
16/44.1k:

a=fmtp:96 352 0 16 40 10 14 2 255 0 0 44100

24/96k:

a=fmtp:96 352 0 16 40 10 14 2 255 0 0 44100

The parameters are exactly the same at 16-bits / 44100 Hz !!

Now we have revealed Apple's big secrets:

1. On Apple TV, up/down sampling is done on the Apple TV itself. (Not a big deal)

2. iTunes ALWAYS down-sampling the audio file to 16/44.1k, no matter the remote end is an AE or Apple TV. In other words, iTune was hard-coded to down-sampling to 16/44.1k while using the AirTunes ................ (This sucks!!)

3. The worst case for playing audio via AirPlay/AirTunes is: playing a Hi-Res file to an Apple TV!! Since the audio file is firstly down-sampled by iTunes and then up-sampled by Apple TV.

Conclusion

If we take a little consideration with the above information, it is not hard to understand why Apple doesn't want to support Hi-Res audio file playback through AirTunes/AirPlay.

To support the Hi-Res audio, they need to :

1. Modify the iTunes codes (so that the audio stream can be sent as it is without down-sampling)
2. Modify the AE/AppleTV firmware to accept the Hi-Res audio stream and decode it correctly.

This is not a trivial change for Apple from development perspective.

Even if I can make a Hi-Res capable AE-like device, I'll need to find an alternative solution for iTunes to get the native Hi-Res support.

SC944-05

Scientific Conversions SC944-05

SC944-05LF Top View

SC944-05LF Bottom View

SC944-05 is a handcrafted transformer made by Scientific Conversions. The suffix LF stands for Lead Free.

SC944-05 Waveform

SC944-05 @ 200mv/100ns Div

SC944-05 @ 200mv/50ns Div

SC944-05 @ 200mv/25ns Div

Since the Vpp of the original waveform is around 3.3V, with PE65612 (1:1), I have to use resistors to decrease the output voltage level to 600mV. In the test above, those resistors were not removed, I think that's why the peak will be lower than the second one. If the listening experience is better than PE65612, I'll remove those resistors since they are no longer required due to SC944-05's primary/secondary ratio - 2:1.

PE65612 Waveform

PE65612 @ 200mV 25ns

Obviously, SC944-05 has less noise than PE65612 with nearly the same rise time. However, the jitter is not something we can see directly from the oscilloscope, but I believe that my ears will tell.

Listening and Conclusion

The listening experience of the SC944-05 is all positive, better resolution, more clear and accurate bass and the harmonics compare to PE65612.

I'm pretty sure that I'l never go back to PE65612 definitely!


Note for Usage

The pinout for SC944-05 is almost the same with PE65612, you can replace Pe65612 with SC944-05 directly except for SC944-05 needs an additional hole for its pin 2.

The pin 2 is for "shielding", which connects to the shield between the primary and secondary coils.
Th shielding will greatly improve the noise suppression, hence, except for creating an additional hole for SC944-05 while replacing the PE65612, remember to connect the pin 2 of the SC944-05 to the ground of the primary on transmitter side, and to the secondary ground if used on the digital receiver side.

Updates

After 3 hours running-in, I got new conclusion:

PE 65612 is NOT comparable to SC944-05, they are not at the same level!

PE65612 vs. S22083/S22160

Newava S22083 / S22160

I did a simple comparison on my current transportation system for Pulse Engineering Pe65612 and Newava S22083 / S22160. Here's the result.

Waveforms

Newava S22083

Newava S22160

Pulse Engineering PE65612

Listening

ON MY SYSTEM, both Newava S22083 and S22160 sounds worse than PE65612 which matched the waveform result. Not only less resolution but also more noise introduced.

Additional Informration

Thanks to Dr. Jon Paul, who gave me some hints and recommendation with similar results.
See Dr. Jon Paul's AES 2003 paper here.

Delta vs. Samsung

Apple Airport Express 802.11n

Open the AAE, you may find that, even with the same AAE model, the factory AAE equipped with different switching power supply modules.

I found that there are at least two switching power supply models.

DELTA Module

Samsung Module

Delta vs. Samsung

Delta @ 2.5 ms

Samsung @ 2.5 ms

Delta @ 1ms

Samsung @ 1ms

The listening experience is the same as the waveform, AAE with Delta module sounds better than Samsung module. This implies that different AAEs (with the same model, 802.11n) may sound different even without modification.

PO74G38072 and DSIX

The Unsolved Misery

Why the PO74G38072 sounds worse than the DISX with TC74VHCU04/PO74G04 ?

This is the question comes up on my mind after replacing the TC74VHCU04 with PO74G04.

My Own Explanation

Well, I'm just guessing, and I could be wrong, so if you think that I'm saying something stupid, share your comment please, will greatly appreciate for that.

Since in the design of DSIX, the output of the 74HC04 buffer is a combination of 5 sets of inverter. While using PO74G38072 on the DSIX, since the pinout is different from 74HC04 chip, I need to modify the connection. In the end, only one of two PO74G38072 buffer outputs is used. 

Take a look at the oscilloscope graph of PO74G38072.

We can see that the overshoot is very weak, actually we should call it "undershoot".

This is where I suspect the jitter coming from.

So why TC74VHCU04/PO74G04 sounds better?

Let's look at the following graph of the TC74VHCU04.

You'll see that in the waveform above, it might be easier for the DAC to tell if it is a rise or fall, so less chance for the DAc to miss interpret the signal. In other words, less jitter. Pay attention to the waveform, the overshoot is obvious.

Ok, now let's take a look at the DSIX design.

Why Mr. Shibasaki uses all the rest 5 sets of the 74HC04 output for the signal?

I guess he wants to create some reasonable "overshoot", since using only one set of the output will become "undershoot" in the end. By combining all the rest 5 sets, the signal level will be strong enough and the reasonable overshoot will be created.

Basically, this is why TC74VHCU04 sounds better than PO74G38072, however worse than PO74G04A.

Conclusion

I think both PO74G38072 and PO74G04 will have better result than TC74VHCU04, however please note that:

1. Do NOT use the PO74G38072 directly on the DSIX, the signal strength is too weak to create overshoot, jitter will be introduced in the end. With DSIX, use PO74G04 instead.

2. If you prefer to use PO74G38072, the circuit must be redesigned for sure.