Does Roon download entire track into RAM? [Memory Playback Discussion]

Power rails where? In the amp?

In the endpoint, such as Linn DS:

https://thewelltemperedcomputer.com/KB/WAV-FLAC.htm

  1. If we measure the power rail that feeds the main processor in the DS we can clearly see identifiable disturbance patterns due to audio decoding and network activity. These patterns do look different for WAV and FLAC - WAV shows more clearly defined peaks due to regular network activity and processing, while FLAC shows more broadband disturbance due to increased (but more random) processor activity.

  2. If we measure the power rails that feed the audio clock and the DAC we see no evidence of any processor related disturbances. There is no measurable difference (down to a noise floor measured in micro-volts) between FLAC and WAV in any of the audio power rails.

  3. Highly accurate measurements of clock jitter and audio distortion/noise also show no difference between WAV and FLAC.

The extensive filtering, multi-layered regulation, and careful circuit layout in the DS ensure that there is in excess of 60dB of attenuation across the audio band between the main digital supply, and the supplies that feed the DAC and the audio clock. Further, the audio components themselves add an additional degree of attenuation between their power supply and their output. Direct and indirect measurements confirm that there is no detectable interaction between processor load and audio performance.

An Linn engineer about the Linn DS

From Naim NDX’s manual directly:

Naim’s UPnPTM servers deliver the uncompressed audio data ripped from CD using the Naim ripping engine to ensure the best quality reproduction. Uncompressed audio data will always give better results than compressed. Even lossless compression may not reproduce audio with equivalent quality to the uncompressed original as the processing required to uncompress the data increases the computational load. This raises the power supply noise floor, which detracts from the sound quality.

Taken from Page 2.

There have been several threads over the years on WAV and FLAC there and using the option to transcode FLAC to WAV before sending to the endpoint.

2 Likes

The Linn stuff just shows that power used by the processor is different when decoding a FLAC versus reading a WAV file. That doesn’t mean there is more noise. Regardless, they go on to say that there is no difference in jitter or noise between FLAC and WAV.

The Naim white paper is 10 years old. That’s an eternity in computers.

If you are using Roon with FLAC or WAV files, PCM is sent to the endpoints so they get the same data and process the same data.

The time of day and power usage in your neighborhood has more of an impact on the power supply than the extra few cycles required by CPU to decompress FLAC files.

1 Like

Yes, it is old and so is my BDP-1 which came out around 2010/2011 as I addressed it in an earlier post. That’s why I have different expectations from the BDP-1 vs. a newer endpoint if I were to get one and given that Roon/RAAT has been out for quite some time. This would allow manufacturers to design with Roon in mind, rather as an afterthought compatability to extend the life of a product.

If you are using Roon with FLAC or WAV files, PCM is sent to the endpoints so they get the same data and process the same data.

You missed the point. The point was that difference between WAV and FLAC was measurable in both systems. Point to be noted was different workload = different impact on the power supply and noise floor. By extension, it is possible that WAV via RAAT, WAV via DLNA, or WAV via MPD might yield differences in noise floor and other disturbances due to the all processes that is associated with each. Whether these differences make it through (Naim) or not (Linn) depends on the particular endpoint. This is why I don’t place any blame or responsibility on Roon. This should be addressed by the manufacturer. However, for the customer that already has the hardware, they have to work with what they have. I get both sides.

If you want to say it’s non-significant or inaudible with the newest processors in optimized endpoints, sure. I can accept that. I haven’t tried any new endpoints. As far as Naim is concerned, I still hear the same WAV and FLAC transcoding discussion on even the newest streamers. Are Naim owners a special breed or is there still something there and going on?

(FWIW, I do have a Torus isolation transformer in the chain. It’s been very stable subjectively in the past 2 years throughout the day.)

My point is, why would I even want my Lumin A1 to do memory playback? I don’t. It sounds absolutely sublime just the way it is.

Why hanker after a feature in Roon that is not proven to enhance SQ, but yet massively compromises the UI and user experience by forcing everything to shift to endpoint RAM before playing? Absolutely bonkers, if you ask me…

Instead of fretting about whether my CPU load is affected by WAV or FLAC, or whether the most recent solar flare is causing EM spikes in the air around my stereo, I just listen to, and enjoy the music.
And I’d advise everyone to do the same! :sunglasses:

2 Likes

And seeing as Roon generally uses an endpoint between core and DAC the stuff you quoted has no relevance unless (and I’m being generous) you connect core directly to DAC. That NAIM blurb is marketing speak aimed at audiophools.

For the same reasons that made you spend an obscure amount of money for a network streamer, like your LUMIN A1, while the same people that use your arguments would say a Chromecast Audio at $35 would sound the same.:thinking:

2 Likes

Naim still recommend using Wav instead of flac for best sq. Most users of Naim set UPnP to transcode flac to Wav to their systems. This is on latest and older systems. And they all say they hear a difference. With the newer one using Roon obviously this is moot, but then there are plenty of users saying UPnP still sounds better on their nd555 £20000 streamers. I personally can’t hear any difference on my Naim Atom. But that’s not saying it doesn’t though.

How does that have no relevance? Those systems are also connected via ethernet and not USB. The difference in both those systems is not due to incoming noise like one might claim with USB, instead its the byproduct of the work solely done within the endpoint. WAV and FLAC difference was just one example of how the workload differs and could be measured. Great job on Linn to filter it out well below, but the difference for them was clear. How many endpoints out there pay that level of attention to all of the endpoints. Again, please don’t get fixated on WAV and FLAC. It’s just ONE example of how workloads differ and produce different footprint within the device.

For example, MPD was described as FLAC->ALSA (MMX and memcpy)…assume it was WAV if that makes you happy.

RAAT’s workload was described as: primarily protocol unpacking, interpreting dynamic network protocol, packet reassembly

I’m not sure what the exact workload of DLNA is and all the processes involved. All of these processes deliver the exact bits, but what are ALL the processes involved to get them there that are running either all the time or periodically.

You could even pay attention to the router for differences between MPD, RAAT, and DLNA. With MPD, whether pulling music off a NAS (ethernet) or Usb drive connected directly, it pulls music every few seconds and then it’s stable. The light flicker intermittently on both the router and USB drive in the same pattern with MPD. With DLNA and RAAT, the lights are flickering non-stop.

MPD, RAAT, and DLNA all produce the same bit-perfect result (just like WAV and FLAC) and are (or can be) isolated with ethernet to avoid the argument of noise coming through from USB. Can anyone here say that all of these are running the exact some processes to make them work? Or is the workload actually different between all these?

Now if you think it’s made irrelevant due to the improvements in CPU processing or how little the workload is compared to running Photoshop or whatever else demanding you can think of, or whether your particular endpoint filters all of this to the point that while measurable but it doesn’t matter (like Linn), or you simply can’t hear it…GREAT. That’s the ideal goal and the dream. The same bit stream sounds the exact same irrespective of the kind/level of work that it took to get it there. No tweaking necessary. Use whatever you want.

You’re speaking bull again, seems to be you’re fixated on that. Chromecast doesn’t do RAAT and unless you’re passing through with an optical cable it’s acting as a DAC too.

I am sorry you did not get my point.

I got it alright, but your example is a poor one.

An interesting fellow you are. I could have used any network music player, even with RAAT, to make my point, that costs ten times less than his LUMIN A1. Would you be happy if I replaced the CCA with a Node 2i?

1 Like

Anything that employs RAAT will do nicely, thanks.

Exactly! :joy::joy::joy: So everything that does RAAT sound the same? As long as it does RAAT?

1 Like

Damn, you got me. Last time I looked RAAT was a transport protocol. DAC’s make sound, transports don’t.

1 Like

So if transports don’t “make” sound, then why a Chromecast Audio as a transport be any different than a RAAT transport?

1 Like

One uses RAAT, the other doesn’t. You’re a clever guy, surely you could figure that out.

Well… enlighten me! You just said “transports do not make sound”. What am I missing here? Bits are bits, no? Bit perfect and that good stuff? Zeroes and ones!

1 Like

Linn have identified the differing behaviours of WAV and FLAC and have taken steps to avoid either of these behaviors affecting sound quality. Naim haven’t. Know which one I’d buy.

1 Like