Article: Apple Music Lossless Mess Part 2: AirPlay

[tgp-2]

First post here on Audiophile Style 😀 ... See attached summary ... I recently looked at various combinations of Airplay-enabled apps, receivers, etc. to verify for myself which support lossless vs lossy transmission ... a lot of overlap with info from the original article here and the discussion thread, but I thought it might be useful for some to see a summary of how things look as of May 2023 ... I tried most of the combinations listed here, and those that I didn't try, I indicate with a "?" (I'm sure folks here can point out any errors or help me fill in the blanks).

Airplay vs Airplay 2 for audio streaming May 3 2023 tgp-2.pdf

[tgp-2]

28 minutes ago, Bevok said:

Thanks for that useful study.

I actually plan on doing some benchmarking soon on Airplay battery use - I’ve always heard that as a negative feature but haven’t particularly noticed it myself. Will advise on my findings if I get time to do it (compare phone airplaying Qobuz for 1 hour vs sitting idle).

I was interested to see that ALL airplay 2 is AAC as I had understood it could take Redbook quality and had thought the aac was a specific choice by Apple Music. How did you determine that? I did a recent data throughput test using an Apple TV (comparing playing a track losslessly using the built in app vs playing the track via Airplay from my phone) and noted over twice the amount of data via the built in app backing up your summary. 
 

Use of a Mac as an Airplay 2 receiver helped ... on the Mac, it's relatively straightforward to observe the incoming network traffic (using System Monitor ... or better still, using an application like "bmon" which puts a numbered scale on the Y axis of the data vs time graph ... System Monitor just shows an unlabeled graph) ... try this with an Airplay 2 enabled app like Tidal

[tgp-2]

hi @Rijckholt ... when you select the Airport Express device from the Airplay dialog on your iPhone/iPad, the uncircled check mark next to the device name means it only supports legacy "Airplay 1" mode ... so Airplay2-enabled apps (Apple Music, etc.) have no choice but to send a real-time 16/44.1 ALAC stream (and when you select an Airplay2-capable receiver, you'll see a circled check mark and an option to select other devices for multi-room playback)

[tgp-2]

14 hours ago, Rijckholt said:

Based on my network traffic I suspect that the Apple Music and classical app are compressing in lossy way BEFORE it is handed over the the AirPlay service of the phone

 

can you describe what you're seeing in the network traffic? ... i can't imagine why a lossy encoding step would be needed right before the Airplay transcode to ALAC

[tgp-2]

5 hours ago, Rijckholt said:

 As for my network traffic: it is just minimal more in line with lossy compressed streaming than with lossless streaming. Just don’t see enough data flowing from my phone to the AirPort Express.

 

getting a good look at the network traffic can be difficult ... it's easier when either the sender or receiver is a general purpose computer such as a mac, raspberry pi, etc. ... where possible i use the utility "bmon" (i'm sure there are other good options) ... the receiving end of an Airplay1 stream will look something like this ...

[tgp-2]

link to an updated version of what I shared in this thread earlier this year in pdf format ... added sections on AirPlay from a Mac and remote controlling lossless Apple Music playback on Apple TV ... note, for the Apple TV use case, my only HDMI connection is to a TV that I think only does 48kHz, so I'm not able to check for any sample rate conversion etc (will leave that to others here who are more experienced and better equipped) 🙂

 

[tgp-2]

2 hours ago, actuel audio said:

So somehow, Apple Music is casting to an Airplay 1 device which can only do Airplay 1 whilst also casting to a couple of independent MusicCast stereo mode speakers.

 

yes, it seems adding an AirPlay 1 receiver to a multi-room group is supported when streaming from Apple Music on a Mac (it's not an option when streaming from iOS), and this forces the use of real-time (AirPlay 1) streams to all receivers in the group

 

but it looks like the Mac's Apple Music app isn't receiving lossless in this case ... the lossless indicator disappears, and a rough check of the network traffic also suggests a smaller/lossy file downloaded to the Mac ... so it's a real-time / ALAC stream, but from a lossy source (and in this case it's not clear why the lossy source would be necessary) 🤔 

 

compare this to selecting only AirPlay 2 receivers ... the lossless indicator returns, and there's more data downloaded to the Mac ... but the buffered AirPlay 2 streams are lower bitrate / lossy

[tgp-2]

16 minutes ago, MgP2804 said:

alac 44.1/16 to multicast by adding a single airplay 1 device. how did you measure this?

 

i'm looking at network traffic using the terminal app 'bmon' (in this case, it's installed on the Mac, and I'm looking at RX received data from Apple Music / cloud to the Mac, and also TX transmit data from the Mac to the remote AirPlay receivers)

 

have also used Wireshark (I/O Graph)

 

there are some example graphs and description in the write-up I linked to earlier

[tgp-2]

summary in above linked Apple forum post is based on output from third party app using BluOS API, not direct observation of network traffic etc.

 

i checked again ... as far as i can tell, there's been no change ... Airplay 2 buffered streams are still lossy AAC 256kbps

 

for reference, my latest summary linked below ...

 

tgp-2 Airplay summary