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.

DSIX with PO74G04

PO74G04


PO74G04 is an alternative ultra high speed solution for 74HC04, the specification is excellent, supports up to 1.125 GHz bandwidth and the propagation delay is less than 1.4 ns with rise/fall time 0.8 ns.

To me, this is an awesome solution as a replacement for TC74VHCU04.




PO74G04 On the Oscilloscope

PO74G04 @ 100ns/100mV



PO74G04 @ 25ns/100mV


Amazing rise/fall time (compare to the TC74VHCU04 in the following graph).

TC74VHCU04 @ 25ns/200mV


The overshoot and the ringing might be the noise from my power supply, will try to improve this later.

Listening Experience

Noticeable improvement discovered.

1. More silent background, this implies the resolution is greatly improved.
2. More solid bass, even when the bass guitar and the bass drum are played at the same time, you will be able to recognize them respectively.

Conclusion

Highly recommended, what are you waiting for?

Home Made PCB Exposure Unit

The following is the very first DIY stuff of mine, every 'JOKE' started from here.

ECL and PECL

Info captured from Internet

ECL and PECL
High-Speed Digital Design Online Newsletter: Vol. 2 Issue 22
Sang Cheol Lee writes:

I am engaged in developing a kind of set-top box. It must receive differential ECL (100K compatible) and then process it. However, I am not familiar with ECL level design. I [would like] to use a single power source (5V for VCC, 0V for GND) , so I prefer to use PECL level devices with TTL devices.

I would like to directly connect the differential ECL signal to the differential PECL device at connector point (first point) of receiver. Is this O.K., or should I use a specific level shifter circuitry or level transformer to connect them? Finally, would I need some special skill to design the connection?

Dr. Johnson replies:

Thanks for your interest in High-Speed Digital Design.

The ECL logic family was originally intended to be used with power supply voltages of 0 V and -5.2 V. The normal logic levels with ECL are:

V(OH) = -0.9 V

V(OL) = -1.7 V

The term PECL means we are using ECL logic with different power supply voltages.

The old 0-V pin connects to Vcc=+5V

The old -5.2-V pin connects to Gnd=0V

The chip is now being powered by 5.0 V +/- 10, instead of 5.2 V. Most ECL chips can tolerate this difference. The PECL logic voltage levels are:

V(OH) = Vcc - .9 V = 4.1 V nom.

V(OL) = Vcc - 1.7 V = 3.3 V nom.

Note that the PECL logic levels are now dependent on the Vcc level. As Vcc changes, the output levels change with Vcc. The common-mode input range of a PECL differential receiver will not tolerate true ECL levels (-0.9V and -1.7V).

When connecting true ECL to PECL, you will need a voltage translation.

If the data has equal numbers of ones and zeroes (for example, with a Manchester-ceded data sequence) then the level translation may be accomplished by sending the signal through a pair of DC-blocking capacitors (0.1 uF capacitors), and then re-biasing the receiver to its mid-range level. Other than this simple case, there is no good, simple way to accomplish the re-biasing.

Best regards,
Dr. Howard Johnson

Gigabit-Ethernet Optical Transceiver Research

HP/Agilent HFBR-53D5




Recommended Circuit on HFBR-53D5 Datasheet




HFBR-53D5 Circuit in Production




Analysis

R3 68R ---> R201 49R9
R2 68R ---> R200 49R9
R4 ---->
R1 ---->
R11 270R ---> R199 274R
R10 270R ---> R198 274R

Power Requirements

VCC = 4.75 to 5.25 V
Icct = 85mA (typical), 120mA (max)

Optical Characteristics

Transmitter Output Optical Power: -9.5 ~ -4 dBm
Receiver Input Optical Power: -17 dBm ~ 0 dBm

This means we can connect the TX and RX directly without attenuator.

Signal Detection

On datasheet page 10:

If Signal Detect output is not used, leave it open-circtuied.

Signal Input/Output

The HP/Agilent HFBR-53D5 is a PECL based solution.

PECL is differential signaling provides noise cancellation, in the the graph taken from Wikipedia, we can realize how it works:



Vee = GROUND
Vlow = 3.4V
Vhigh = 4.2V
Vcc = 5V

Conclusion

Most of the digital audio source signal is based on TTL, if we are going use the HP/Agilent HFBR-53D5 for the inter-chassis transmission, obviously the TTL needs to be converted to PECL on the TX side and then be converted back to TTL again on the RX side.

Another possible solution will be TTL based optical transceiver which supports 20Mbps or above, however I couldn't find such kind of transceiver.

Possible Solution for TTL/PECL Conversion

Here are some possible solutions :

PO100HSTL179A
TB5D1M/TB5D2H
MC10ELT28

[ To Be Continued ]

Alternative Transmission Consideration for Digital Audio

Just to post some photos of the optical transceiver for high speed network transmission here.

Pulse Transformer on 10/100 BaseTX



Optical Transceiver on OC3/ATM






Optical Transceiver on Gigabit-Ethernet



Optical Transceiver on OC48







XENPAK Optical Transceiver on 10GE



The Question on My Mind

What if we use those solution to replace the TOSLink?
What will happen? Interesting ................

RTFM

Please Read the Specification of Your Scope

Many DIYer like myself, focused on the bandwidth of the oscilloscope itself.
However, when measuring the signal, the bandwidth of the probe will be another important variable needs to be taken into consideration.

The Probe Spec Example




If we take a look at the specification of the probe in the example above, we might notice that the probe only supports up to 6MHz at 1X position.

The Difference between 1X and 10X

Here's SPDIF signale measured with Probe at 1X



The following is the SPDIF measured with probe at 10X



As we can see, if we measure the signal with probe at 10X, the result gives us more clue for the noise.

Well, the old saying is right, RTFM.........

PO74G38072 Digital Buffer

Background

Toshiba TC74VHCU04 is a well-known digital audio buffer chip since it was used in the famous DSIX circuit.
The PO74G38072 designed by Potato Semiconductor is a buffer chip for digital signal, supporting up to 1GHz. PO74G38072 was recommended by some DIYers as a alternative solution for digital buffer than the TC74VHCU04 due to the wide-bandwidth and its perfect specifications. I did a simple test, replacing the TC with PO chip, and the following is my discovery.

Listening difference

It was a surprise to me......... Surprise? So, better or worse?

Unfortunately, after swapping TC74VHCU04 with PO74G38072, my system sounds worse.
Actually, the two chips sounds nearly the same, however TC74VHCU04 provides more silent background than PO74G38072.
As a result, the TC74VHCU04 gives more dynamics in general.

Investigation

I then tried to find out the reason technically.

Here's the comparison of the TC74VHCU04 and Po74G38072 on the oscilloscope:

TC74VHCU04@100ns/200mV


PO74G38072@100ns/200mV


Let's take a closer look:

TC74VHCU04@25ns/200mV


PO74G38072@25ns/100mV


As you can see, TC74VHCU04 has less ringing and overshoot than PO74G38072. In other words, less noise.
I think basically that's why TC74VHCU04 sounds better than PO74G38072 on my system.

Conclusion

I do believe that PO74G38072 should have better performance than TC74VHCU04, since it supports more bandwidth than TC. However, wider bandwidth sometimes means that the noise will passthrough the buffer as well. And I think that is basically why PO sounds worse than TC on my system. (Please note what I'm saying - my system)

But if I can decrease the noise on the power supply, I think there is more chance that the PO might sound better than TC for one reason - less jitter. PO is a much faster chip than TC, if we can well control the noise level sourced from the power supply, I do believe that the less jitter characteristics of the PO chip will be easily identified in this case.

I think the power supply will be the next task for me.