How i read the quote from Steve, is that the difference is mainly about either using local memory to buffer data before processing (UPNP) or processing the bitstream directly from the source (Roon). It wouldn’t follow a different signal path after the bits are read, so it wouldn’t appear to be something that could influence sound quality. The word ‘stack’ is perhaps a bit misleading in this context, since it could imply something that pertains to the processing of the actual audio signal, which wouldn’t be the case.
1 Like
Correct the new streamers use a method with UPnP at the network buffer layer to read the data as fast as possible and spool it as it’s then fed up to the application sample data clocking stage into the SHARC processor… this way the streamer is better insulted itself from interruptions to the stream from poor consumer home networks.
Roon require a specific synchronisation and latency requirements… to be certified as Roon Ready therefore the extent this spooling is used for Roon before sending the data to the audio layer is limited … so yes that means if the user had a poor wifi connection for their connected streamer playing a RAAT PCM stream they will have a greater probability for a dropout with Roon compared to UPnP media transfer.
The Roon approach is to use the Roon Core function to do this spooling instead of at the client. From a SQ perspective this is mostly moot… other than with less client processing with Roon in many circumstances Roon on a Naim streamer can have a small SQ advantage… but I don’t hear this… other than a slight sonic shift as I said earlier on…
It is fair to say, if you over ride the Naim Roon default settings, and require RAAT to decimate from 32 bits to 24 bits, then this does negatively impact SQ… this to my ears is quite noticeable and un attractive in my setup driving a Dave / HMS and it also raises sibilance
We are in agreement.
Just one thing to preempt any misunderstandings:
My use of “stack” was only to refer to the early part of the linked LJS thread that was about the Qobuz app, where Chromecasting still leaves the app out of the signal path and only instructs the NDX2, but then (as Steve did confirm) the NDX2 nevertheless uses the Chromecast stack, which is inefficient and therefore creates a higher processing load on the NDX2 with at least a theoretical SQ effect. In this part, regarding Chromecasting from the Qobuz app, I don’t disagree with LJS at all.
But this part of the old thread, and Steve’s answer in it, is totally separate from the later part of the thread that was about Roon, and it’s the Roon thing that is under discussion here in the current thread.
Steve gave a separate answer for Roon at the very end of the thread, the one I quoted further up, and this is where my and LJS’s disagreement comes in.
(I suppose you were referring to Steve’s use of “stack” in this part and while I most likely agree with you, who knows why he used it.)
Exactly, and Roon strongly recommends against wifi between core and the network (though I believe in part also for app responsiveness i.e. metadata delivery to app), and I believe also recommend a wire from router to streamer.
I have been a Naim owner since the late 70’s.
Apart from my UnitiServe which required a return to base 2 or 3 years after purchase, nothing has ever missed a beat!
In a way, the app does have a bearing on the SQ (weather you can hear it or not). Steve clearly stated that when using the NDX2 as a Roon endpoint, there IS a difference on the SW stack that is used on the NDX2 to play the received data. And I read that answer to state that the SW stack used on the NDX2 when going through Roon is in his view sub-optimal to the stack used when using UPnP or when streaming from Qobuz. The latter 2 stacks, I read to be equivalent in Steve’s opinion.
Hypothetically speaking yes, there is a difference. But it would be very difficult to determine whether it would or could be audible, and if either would be measurably better than the other. Perhaps it would in theory be measureable using the very sensitive equipment that Naim has in their lab, but it’s doubtful i think that it would translate into audible effects.
The UPNP scenario causes a tiny amount of extra noise in the streamer when reading the ram buffer (cpu + memory access), the Roon scenario causes a tiny amount of extra electrical noise when reading the PCM stream (network access). I think it would be very difficult to measure the degree to which these influence the audio coming out of the DAC.
In any normal usage scenario, i think they will both sound equally good to an attentive listener.
I do feel that local processing would in principle be preferrable since it reduces the amount of potential failure points to one, the local streamer. When streaming PCM directly to the streamer it requires both the Roon system and the streamer to function optimally and stay in perfect sync during playback.
The UPNP scenario causes a tiny amount of extra noise in the streamer when reading the ram buffer (cpu + memory access), the Roon scenario causes a tiny amount of extra electrical noise when reading the PCM stream (network access)
However, even when the large buffer is used in the UPnP scenario it is not as if there is no network access. While music plays from the “start” of the buffer, the buffer needs to be refilled “at the back” with data to be played later.
When streaming PCM directly to the streamer it requires both the Roon system and the streamer to function optimally and stay in perfect sync during playback.
While true, this is simply done by RAAT and there is not indication that this isn’t working
True, although i believe it was stated that the entire file was read into the buffer before playback. The buffer on the modern streamers is apparently large enough for this. So this would avoid most additional network access during playback.
Yes i’m sure it works fine in practice, it was mainly as a point in principle (less potential points of failure is preferrable). For local networks it is likely more than stable enough for daily use.
up at the application level - i would think there is a ram spooling for all modes - its just the size of the buffer that varies between application. Cloud streaming/upnp large, Roon low to meet latency requirements.
1 Like
Sure, it is first filled or else a buffer would have no point, but I don’t think that playback waits until it is fully filled - else someone with a 25 Mbit/s data rate would have to wait 16 seconds for playback to begin. (50MB buffer)
In any case, with short tracks you want gapless playback, not wait for the buffer to fill from scratch on every track change. When playing tracks that are longer than the buffer covers, obviously they play continuously too
I am intrigued - were you not once of the opinion that the unit reporting 32 bit to Roon is overstating and it would be better to change the setting in Roon to 24 bits? I think I read several older posts of yours about this while I researched Roon.
Yes, although 25mbit/s might be a bit low for local networks ofcourse.
Also the PCM stream will be roughly 50-100% larger than for instance a FLAC, so it will require more bytes to be moved and buffered, which will cause some extra noise.
All theoretical ofcourse, i don’t really think this has any real world implications… 
For local yes, but not for Qobuz internet access, where the large buffer is even more important. 25 Mbit or even 50 (still an 8 sec wait) is a common lower-tier internet service in Germany (and way more than even Netflix 4K needs)
That’s true, but if you’re reading a 16bit FLAC from Qobuz, it will probably still be 3-4 times less bytes than have to be read when for instance streaming 32bit PCM from Roon to the streamer. So i think it’s safe to say that the latter scenario will require a lot more network activity and buffering…
Sure, but my point was that there is network activity during playback regardless of the buffer size as even if the 50MB RAM buffer is used and the music plays from this buffer, the buffer still has to be topped up continually or else it will deplete
I agree! 
1 Like
It’s so easy to agree with you every time and I appreciate you don’t seem to mind too much if I press a partial point in order to not leave ambiguity. 
1 Like
Interesting topic in places.
I have had 6 Naim products with no real issue.
However, through this forum and a Facebook group I have procrastinated about updating to a Nova due to individuals experience of screen freezes, reliability etc.
It’s illogical I know, because all manufacturers of any product can have issues but it’s making me very cautious about purchasing the Nova.
Strangely an amp and separate streamer doesn’t worry me so much!!!