• The move to the new server is done. There are some software and database maintenance updates in process. This has us passing the hat around to help out. We appreciate any donations. Seriously, even a dollar helps. The payment page may be found here - https://www.audiokarma.org/support.html

How can the same down load sound so different?

The OP's "Givens" as stated are:

The same 256 kbps AAC song file is stored in his iCloud library so there's just 1 source file.
There's 1 AppleTV device so just 1 DAC.
He is using 4 devices to play the same file and they sound different.
At least 3 versions of the OS are used.
He wants to know why.

Additional unstated "givens":
Since he's using iCloud he is not streaming Apple Music, he's using iTunes.
4 players = 4 digital transport hardware sets.
At least 3 internal RF antennas and transceivers are used.
2 completely different operating systems OS for computers and iOS for mobile devices are used.
There are at least 2 WiFi protocols in use - The early 2009 iMac (24") uses 802.11n and is 802.11a/b/g "compatible" and the "newer" 27" iMacs use 802.11ac and are 802.11a/b/g/n "compatible".

A Little Math:
4 hardware sets + 2 OS's + 2 WiFi standards yields 70 possible hardware and software combinations.

The Real Question:
Why would they all sound the same?
 
elcoholic said:
The OP's "Givens" as stated are:

The same 256 kbps AAC song file is stored in his iCloud library so there's just 1 source file.
There's 1 AppleTV device so just 1 DAC.
He is using 4 devices to play the same file and they sound different.
At least 3 versions of the OS are used.
He wants to know why.

Additional unstated "givens":
Since he's using iCloud he is not streaming Apple Music, he's using iTunes.
4 players = 4 digital transport hardware sets.
At least 3 internal RF antennas and transceivers are used.
2 completely different operating systems OS for computers and iOS for mobile devices are used.
There are at least 2 WiFi protocols in use - The early 2009 iMac (24") uses 802.11n and is 802.11a/b/g "compatible" and the "newer" 27" iMacs use 802.11ac and are 802.11a/b/g/n "compatible".

A Little Math:
4 hardware sets + 2 OS's + 2 WiFi standards yields 70 possible hardware and software combinations.

The Real Question:
Why would they all sound the same?
Click to expand...
Clearly they don't, but why they don't is not so easy to explain.

That's because the operating systems, operating system versions, and WiFi protocols make no more difference on digital sound than the colour of the case of the computers. Even the WiFi antennae and transceivers have no effect on sound, as long as they're working correctly.

In analog systems, every link in the analog audio chain has an effect on the sound. Not so for digital audio systems. A digital audio chain may have many, many links -- even some partially broken ones, but that doesn't matter due to error correction (up to a point) -- and still produce exactly the same data at the output as at the input. And a given DAC will produce the same sound given the same data stream every time -- assuming jitter or latency is limited, typically via clock reconstruction and buffering -- no matter where it comes from or how it gets to the DAC.

But that only works up to a point. When the level of network problems or bandwidth limits force the digital transmission protocols to drop data in order to compensate for low bandwidth, the result will be reduced sound quality.

Thus it seems likely the difference in sound is either due to different data streams being sent to the Apple TV depending on the source device, because different digital data has been downloaded to the Macs/iPhone or is being accessed on the Apple TV (for reasons as yet undetermined, but perhaps due to quirks in the way AirPlay/iCloud/etc work) or due to network problems forcing lowered bandwidth.
 
DaveVoorhis said:
That's because the operating systems, operating system versions, and WiFi protocols make no more difference on digital sound than the colour of the case of the computers.
Click to expand...
You're leaving out the most important variable - completely different hardware with differing computational power, process load and power supplies. I've found that to be the case time after time.

And yes, fine tuning the kernel of even a stripped down version of Linux for latency-free music playback can make a difference.
 
Last edited:
E-Stat said:
You're leaving out the most important variable - completely different hardware with differing computational power, process load and power supplies. I've found that to be the case time after time.
Click to expand...
That's true for a processor synchronously coupled to a DAC, but unless AirPlay and Apple TV rely on the controller acting as the source rather than instructing the Apple TV to pull from the source, it's unlikely to be the case. It's possible that it is the case, but unlikely -- particularly for iCloud/iTunes sources -- as passing the data through the controller would be overcomplicated and unnecessary.

Using a very similar technological approach, the sound output of a Google Chromecast is completely unaffected by whatever device is being used as the controller -- because the Chromecast pulls data directly from the source, not the controller -- but is certainly affected by the data format of the source and network quality.
 
DaveVoorhis said:
That's true for a processor synchronously coupled to a DAC, but unless AirPlay and Apple TV rely on the controller acting as the source rather than instructing the Apple TV to pull from the source, it's unlikely to be the case.
Click to expand...
I observed a way to determine that in post #36, but it seems @twiiii has left the conversation.
 
E-Stat said:
I observed a way to determine that in post #36, but it seems @twiiii has left the conversation.
Click to expand...
Yes, he appears to have bailed.

Note that turning off the controlling iPhone might turn off the stream if the software sends the "off" signal before it goes down. However, it should be sufficient to simply take the phone out of wifi range, or -- as works with Google Play and a Chromecast -- turn off wifi. The Chromecast happily keeps playing indefinitely, and the phone asks to reconnect to it when wifi connectivity is restored.

Tomorrow, I'll see if I can borrow an Apple TV from work -- there was an unused one in a box of miscellaneous Apple kit -- to experiment on if it's still available.
 
Provided the DAC FIFO buffer does not overflow or underflow, processor performance and PSU will have only a secondary effect on audio quality, via coupling of noise into the analogue circuitry.

Maintaining the FIFO state is the priority of any digital to analogue streaming system, be it audio or RF. If the FIFO overflows or underflows, it's considered a significant failure; for an RF transmission system, it will often trigger a channel shutdown and re-start, in order to prevent channel splatter. VoIP allows for buffer repeat or drop, in order to cope with the different source and destination clock rates. A system with the DAC clock as timing master has to propagate data requests back to the source; that's how network-based protocols, such as DLNA, and 'asynchronous' USB interfaces work.

This assumes the usual mechanism of a DAC data clock that is independent of the data processing.
 
DaveVoorhis said:
Tomorrow, I'll see if I can borrow an Apple TV from work -- there was an unused one in a box of miscellaneous Apple kit -- to experiment on if it's still available.
Click to expand...
That might shed more light to this question than all the speculation!

I’ll confess ignorance to the true meaning of “cast”, but my impression it is different from merely “remote control”. There once was a LMS plug-in for XM, but it was not updated following a big change. I do have access from phone/pad and understand there is a plugin that would allow those to serve as source and send the bitstream to LMS for playback on the endpoints. In that case, the phone very much becomes a significant player (pun intended!) in sound quality.
 
cpt_paranoia said:
Provided the DAC FIFO buffer does not overflow or underflow, processor performance and PSU will have only a secondary effect on audio quality, via coupling of noise into the analogue circuitry.
Click to expand...
That is quite contrary to my experience using different power supplies with both my endpoints.

Do you really think that crappy switchers deliver the same performance as linears or battery/capacitor based supplies? I find they always add false brightness or a “tizz” on top that masks resolution.

Power supplies always make a difference with every aspect of audio performance.

I find that empirical evidence always trumps theoretical since the latter assumes that every possible factor has been considered.
 
Last edited:
E-Stat said:
I’ll confess ignorance to the true meaning of “cast”, but my impression it is different from merely “remote control”. There once was a LMS plug-in for XM, but it was not updated following a big change. I do have access from phone/pad and understand there is a plugin that would allow those to serve as source and send the bitstream to LMS for playback on the endpoints. In that case, the phone very much becomes a significant player (pun intended!) in sound quality.
Click to expand...
The term "cast" -- mainly per Google -- refers to systems where the controller instructs the DAC to retrieve and play an audio or video data stream, leaving the controller free to do other things and not otherwise be involved in processing the data stream. E.g., https://www.pocket-lint.com/apps/ne...at-speakers-support-it-and-why-does-it-matter, particularly the "What is Google Cast for Audio" section.

Casting systems often have plugins/apps/whatever to optionally allow the controller to also act as a source.

In the OP's case, it's not clear whether the controlling iPhone/Mac/MacBook/whatever is acting purely as a casting controller, or is also acting as a source.
 
E-Stat said:
cpt_paranoia said:
Provided the DAC FIFO buffer does not overflow or underflow, processor performance and PSU will have only a secondary effect on audio quality, via coupling of noise into the analogue circuitry.
Click to expand...
That is quite contrary to my experience using different power supplies with both my endpoints.
Click to expand...
It takes a broken power supply to degrade a purely digital system, but even a good power supply can introduce perceptible noise into analog circuitry. Thus, as cpt_paranoia says, the PSU will only have a secondary effect on the analog circuitry, not -- if working properly -- a primary effect on the digital transport.
 
E-Stat said:
Thanks for the reference Dave.

So why the obfuscation of not simply calling them a remote control?
Click to expand...
You can run most audio kit without a remote control, which is mainly there to adjust volume and skip tracks without shifting your fat arse from its sweaty groove in the couch and risking spilling the popcorn. A typical receiver or CD player without a remote is at worst annoying, and it's not really involved in selecting media, or at least not much.

But casting systems depend on the controller for all operation, including selecting media sources, along with the usual volume adjustment and whatnot. A Chromecast without a controller is, at best, useless. The role of the controller in picking what you hear (or see, for videocasting) is fundamental.

Perhaps the terminology was intended to highlight this distinction, or maybe the Google marketing department thought Chromecast sounded cooler than Chromeremote?
 
E-Stat said:
That is quite contrary to my experience using different power supplies with both my endpoints
Click to expand...

That's probably because you have never experienced primary failures; loss or corruption of data in the path. That's a testament to the people who designed the transport protocols.

I have experienced primary data failures, whilst developing various digital audio, video and RF transmission systems. Primary data failures are very noticeable...

You will note I did not claim that power supplies and processor noise have no effect; no dispute there. There are design techniques to reduce those secondary effects.
 
DaveVoorhis said:
But casting systems depend on the controller for all operation, including selecting media sources, along with the usual volume adjustment and whatnot.
Click to expand...
Both of my endpoints are headless and require a remote control. The apps work no differently when using devices like the original Squeezebox Touch having their own UI.

That explanation is just jibberish.
 
E-Stat said:
Both of my endpoints are headless and require a remote control. The apps work no differently when using devices like the original Squeezebox Touch having their own UI.

That explanation is just jibberish.
Click to expand...
No, it explains the terminology.

Note that the definition should also include the controller instructing the DAC to retrieve a stream -- i.e., "casting" a stream -- rather than the controller transmitting the stream or the device hosting it locally, like an iPod or typical MP3 player.

Had Google invented the Squeezebox Touch, they probably would have called it the Squeezecast or Squeezebox Cast.
 
E-Stat said:
In the real world of audio performance, they can have a profound effect on transparency and dynamics.
Click to expand...
What effect do you think the power supply has on the digital output of a purely digital device?

What effect do you think the power supply has on the analog output of a purely analog, or mixed analog/digital device like a DAC?

What physical quantifiable effects on digital data or analog waveforms do you think account for the qualitative experience of transparency, or dynamics?
 
Actually, thinking about it, power supplies probably fall into the tertiary problem category...

1. Data loss or corruption
2. Compression algorithm (if lossy)
3. Noise and interference sources

You're doing something very wrong if 3. moves up the list...
 
You must log in or register to reply here.
Back
Top Bottom