I don’t know whether Wav sounds different to flac. I’ve streamed both, can’t say I noticed a difference, but not interested, so not compared.
However, I’ve streamed from qobuz using both streamer app and chromecast. They obviously sound different even though the same data is streamed from qobuz.
Why does that happen?
You are potentially making the exact same mistake you accuse of here.
You should know that when used as a transport and sent over SPDIF to a DAC, the transport is the master clock and the raw PCM data contains zero clock information. So differences in transports is almost certainly down to timing deviations. I don’t know if digital noise may also be carried over an SPDIF link.
This also applies to people with wide knowledge of electronics.
Measuring stuff will not give an indication of how something will sound.
HiFi equipment/systems contain 100s of components they all have different electric characteristics.
Most hifi manufacturers choose components based on how they sound, not on how they measure.
That does not happen these days.
Didn’t happen in the ndac and that is 15 years old.
Naim’s own whitepapers on the NDX and ND555 say it does. When fed via SPDIF, they make micro adjustments to the incoming clock signal to try and manage the buffers they use.
Whereas the ND 555 operates as clock master for audio signals ‘pulled’ from a network, with an S/PDIF input the signal is clocked out by the source component and that clock has to be recovered and de-jittered by the receiver.
In the Naim DAC stepping of the clock frequency was achieved by providing 10 selectable fixed clocks, which gave quite large intervals between available clock frequencies. In the ND 555, by contrast, fractional divider clocks are used to provide much finer gradations of clock frequency to allow much closer matching of the incoming and outgoing data rates. In this way the ND 555 is able to adapt its clock frequency to that of an S/PDIF source while completely decoupling its DAC circuits from clock jitter generated either by the source or within the S/PDIF interface.
The ND 555 does this using a refinement of the method first developed for the Naim DAC. As the recovered clock frequency will never exactly match that of the ND 555’s own clock oscillators, a means is required to adapt the ND 555’s clock frequency to that of the incoming data. This is achieved by sending the data to a FIFO (first in, first out) buffer, from which it is clocked out under control of the ND 555’s own clocks. Disparity in the incoming and outgoing clock frequencies will either cause the buffer to become fuller with time (if the incoming data rate is higher than the outgoing data rate) or less full (if the incoming data rate is lower than the outgoing). The ND 555 monitors the state of the buffer and, over long time intervals, step-adjusts its internal clock frequency in order to keep the buffer roughly half-full.
In the Naim DAC stepping of the clock frequency was achieved by providing 10 selectable fixed clocks, which gave quite large intervals between available clock frequencies. In the ND 555, by contrast, fractional divider clocks are used to provide much finer gradations of clock frequency to allow much closer matching of the incoming and outgoing data rates. In this way the ND 555 is able to adapt its clock frequency to that of an S/PDIF source while completely decoupling its DAC circuits from clock jitter generated either byvthe source or within the S/PDIF interface.
The implication as I read it is the outgoing clock from the buffer has to vary unless you get a very accurate match.
A crap carrier and even more crap carrier I suspect
That doesn’t mean the clock in the transport is the master clock.
The ND555 has its own master clock.
The info you posted describes how the buffer is maintained at 50% full.
What does crap carrier mean?
yep
HI Pete, thanks for you comment, although I am not particularly qualified in consumer electronics design - but many of the cases are equally valid across many disciplines, though I do realise because of the big ratio between component cost and retail typical in hifi, often key design compromises need to be made within the product cost budget to be commercially viable… and these compromises are not typically explained.
I think one thing that doesn’t help is that often sales marketing product literature for consumer products such as hifi seem to focus on over simplifications and generalised concepts - which yes I am sure helps readability and makes concepts accessible, but can also I suggest give the un informed reader a false understanding of how actually certain things work in the real world - as opposed to a simplified abstraction. Not being disparaging, but you even some many examples of this on this forum.
If one is really interested in such things and one wants to gain a greater understanding - you can do a lot worse than join the AES (Audio Engineering Society) as an associate member where you can get access to its vast constantly growing library of videos, technical documents and publications describing and exploring many of the concepts touched on in this forum. Not all the texts and publications are complicated research and development papers.
We’ll have to disagree on the reading of the first paragraph then.
Oh dear! Can we end this dicussion? The decoded PCM data handed to the DAC is bit-for-bit identical, unless when comparing WAV vs FLAC on the same legacy player.
Ironically, the transport example actually supports the opposing view: they sound different precisely because their output streams are not identical. Remove the real differences, and you remove the sonic difference.
Using the Naim app to play a track from Qobuz means the streamer downloads the file (quite quickly) over the network into cache, then plays it out from cache itself.
If you use the Qobuz app on your phone/tablet and then Chromecast to your Naim streamer, then the phone/tablet is doing the downloading and sending it almost realtime over the network to the streamer using Chomecast protocols.
Very different paths, and I’m not sure what Chromecast (or Airplay) do to allow for timing accuracy there. WAV and FLAC files contain no timing information. Timing is always supplied by one or more devices in the playback chain.
That doesn’t happened.
The data isn’t transmitted via the phone / tablet. It goes direct to the streamer.
Not with Chromecast. Are you confusing it with Connect?
No. 
It is possible to stream chromecast via phone.
I did it once by accident, but the default is to stream direct to streamer from qobuz.
It’s worthwhile remembering when data is sent to a DAC is in a stream of data … there are two key variables… the sample value itself and time. People often only focus on the sample value data… so called ‘bit perfect’ .. they forget about the time. The time is locally created or reconstructed… and distortions in time, an analogue value, will adjust the sound from the identical sample data.
Noise can and typically does modulate clocks creating the time creating phase distortion of the clock. Once you gave introduced errors into a system it can be difficult to remove… even if clocks are separated.
Fatcat is correct, Chromecast sends the audio stream direct to your streamer, not via your phone, which is just working as a controller. Airplay, on the other hand, always routes the stream via your phone.
My apologies to @Fatcat Every day is a school day, being an Apple user I wrongly assumed chrome/google cast worked the same as AirPlay.