How convenient that it’s something that cannot be defined.
The human ear can discern volume differences below 1 dB down to 0.2 dB, but they are not recognized as volume differences and instead are experienced as a difficult-to-define quality difference.
Therefore, it is another case where it makes no sense to discuss unless this is ruled out by measurements.
I wonder why people believe their ears over the opinion of the software director who builds the stuff they bought.
I’ve looked at this more closely and done more research.
I think the issue is probably related to buffering within the NDX 2 and the impact of increased processing in electrical noise - which impacts on the analogue conversion. So, “bits may be bits”, but this is impacting at the point of analogue conversion.
According to various sources, the NDX 2 apparently uses a 50mb buffer - which means it loads most or all of an entire track at the start, whereupon there is no network traffic. RAAT uses a much smaller buffer - meaning there is constant network traffic to the NDX 2. Assuming that the network is still fast enough to minimise jitter, it nonetheless means the Naim is constantly processing ethernet input and buffering it. This processing creates noise - which ultimately manifests itself in noise affecting the analogue signal.
Naim has published a white paper on the original NDX. The paper shows the designers deep concern to minimise processing to reduce the noise floor. So, for example, the paper says
‘Naim’s UPnP™ 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.”
and
‘The NDX uses the same 16x oversampling filter as the Naim DAC, which is implemented in the SHARC processor. The chosen filter is a modified Butterworth to which additional poles have been added to prevent too much phase shift occurring within the audio band. To ensure both low arithmetic noise (fewer additions and multiplications that cause rounding) and low power supply noise (since the DSP draws less current when it isn’t calculating) the filter is implemented as efficiently as possible, using only five lines of assembly code.
In addition, all code that runs in the SHARC processor has been tuned by listening tests to maximise sound quality. With every increase in number crunching the DSP consumes more power, and the more power the DSP consumes the greater the power supply noise. By optimising the DSP algorithms and controlling the way the data is buffered, power supply noise is kept to a minimum – to the benefit of audio performance.”
There is also an interesting quote from Steve Harris on Chromecast, sourced from this forum or the Naim forum
‘When using Chromecast the stream is bit perfect and native upto 192kHz/24bit. The downside of Chromecast + Qobuz is that it’s not really designed to run at such high sample rates. The buffer sizes are far too small (hence prone to drop outs) and the Chromecast stack is very inefficient so uses nearly all the CPU time in the streamer. Not only is this bad for unit response times, but not also great for sound quality as the electric noise floor of the product increases as everything works harder.’
While no doubt Roon uses larger buffers than Chromecast, this quote recognises that repeated buffering has an impact on processing and therefore sound quality.
(As an aside, my old Rega Apollo CD player also used a larger buffer - perhaps reputedly distinguished its sound quality too).
On another topic, I’m sure what the snark is about identifying issues through listening. Isn’t that the whole point?
Just to show evidence using Roon’s signal path as gospel 
I support @CrystalGipsy and this is for @Marin_Weigel to ponder over.
Being a clever boy, I remotely accessed my computer and I played my (I was wrong) only 32bit-768kHz album.
With playback to the Roon Bridge on my RPi4 it plays 32bit as my DAC supports it. It downsamples to 384kHz as that’s the max my DAC supports in this test. I have other DACs that support it, but not testing them as they aren’t turned on.
I then enabled Squeezebox streaming in Roon and played to the Squeezelite zone on the same RPi4 as above. It bit rate converts to 64bit float, downsamples to 192kHz and then bit rate converts to 24bit.
Therefore I conclude that Squeezelite on the RPi4 running RoPieee doesn’t support 32bit.
So not all streaming transport protocols are equal in terms of capabilities. Some Roon Ready implementations don’t feedback to the signal path when DSP on the streamer is active. So there is food for thought on that side of things.
If I setup my FiiO R7 as a Squeezelite player device it’s also does the same as the RPi4.
My comment of LMS not supporting 32bit may need clarifying and I amend this to: LMS to my RPi4 with Squeezelite enabled doesn’t support 32bit.
And yes, the signal path incorrectly identifies my 8300CDQ as a 9000A. RoPieee shows it as a 8300CD USB interface. Which is correct.
Although we listen with our ears, we actually feel music with our whole bodies. Vibrations, emotion and visually if looking at the musics information at the same time. It may not be scientifically proven, but I believe this and also how one controls their music playback, the interface, the experience and reliability of software can have an effect on what we perceive to sound ‘different’. We cannot measure sound quality, only if it’s bit perfect from server to digital input on a DAC.
Just listen to the music and enjoy folks 
“Just listen to the music and enjoy folks ”
Best advice ever!
That claim is like 20 years old, you haven’t discovered anything new. In Naim land, the predominant lore is that processing needs to be kept off the streamer/DAC as much as possible.
And guess what, Roon performs less processing on the endpoint than when using Naim streaming from streaming services (or UPnP unless you configure the UPnP server for server side transcoding).
The NDX has zero to do with the NDX2 and its new streaming board. Since the release of the NDX, people have known that it was underpowered and many people preferred transcoding on the UPnP server, whether with good reason or not.
Funnily, transcoding on the UPnP server is more or less the same as the PCM conversion performed on the Roon Server. They both keep processing off the endpoint.
Yeah, everyone who is into Naim and on the Naim forum knows this quote and others.
It’s even funnier that you believe this one from Steve but steadfastly ignore what he said about Roon.
The snark is about the purposeful ignorance of the very audio science without which none of these devices would exist, and the misused elevation of known-imperfect audio perception to an objective measurement instrument.
I think that’s Roons limits though rather than squeezelite as general rule as it is possible to playback as Marin shows. As I said I never was able to enable higher when I had a squeezebox nor using UPnP bridge with Roon which uses Squeezelite to talk to Roon.
If NAIM has a hard time keeping system noise from leaking into their DAC, it’s a strong argument for not using their products and/or for using separates that don’t allow noise from the streamer processing to affect the DAC.
Because half the people in here are already wrong, and we don’t need some stupid AI muddying the waters with dubious information and hallucination.
They are admitting to poor PCB layout and inadequate power supply design. Off course they are known for selling additional power supplies for their equipment at outrageous prices to make up for any designed in deficiencies.
I have yet to read or see any actual evidence that computational load has a negative impact on SQ other than in extreme cases (e.g. overloading a component to the point where data drops and output falters). Can you point us at any objective evidence (i.e. not marketing materials)?
Because Generative AI only produces something that is statistically likely based upon a given corpus, and not something that resembles “truth” - see this for a simple explanation:
https://theprogressivecio.com/the-tldr-of-this-years-best-explainer-of-chatgpt/
I’ve done the same test using PS Audio’s test file and Direct Stream DAC. Same results. Roon is bit-perfect. What happens next is up to the DAC and other downstream components.
Why I use Roon.
I have Qobuz and my CD collection on a network hard drive. Roon allows me to integrate these libraries and play back on multiple devices in my home. It also allows me to upsample (not sure if makes a difference) and to play DSD files seamlessly. I upsample all 44.1/88.2/176.4/353.8 files to DSD and all other files to 384K.
Roon actually does everything that someone with the hobby I have wants to do. It is fun.
I have an old Denon dnp720ae streamer. It must be 15 years old. It is integrated into my system and I can listen to music (via Airplay) from my IPAD using the Qobuz app. It sounds wonderful. When I do A:B comparison to using my Mac Mini outputting to my Zen One Signature DAC connected to the same receiver with a balanced cable the difference in SQ is stark.
I am writing this because it is part of the sickness of a hobby we have. If I only listened to the Qobuz via Airplay and never upgraded I would be very happy. It sounds great.
I have no real point here other than I, like a lot of you, like playing around with this. If all I cared about was value I would have Spotify and stream it from my phone to my receiver via Bluetooth and, if that was all I ever heard, would sound great.
I love Roon. It is a playground for me. It also allows me to play the DXD/DSD/384 files I have purchased with accuracy. I could have streamed all those on Spotify or Amazon, but I chose to purchase them. I chose to play them back with Roon
and… you could aways add hqplayer
