Well I did read it and I don’t appreciate you saying I am twisting any words. Expecially while using a partial quote that attempts to make it seem as if I said the opposite of what I actually said. Look, to each their own. I don’t hear a difference nor see a technical reason for any, so I have no reason to unravel this further. You have your own interpretations of what Steve said, that’s fine too, and if you hear a difference, or if you don’t but nevertheless don’t need clarification from Steve, then it is fine if it ends here.
Do you think I misunderstood?
As for the app, I haven’t mentioned it as I know it is unrelated to Roon, and I also don’t think that LJS referred to the app either in the last part of the thread where Steve’s post about Roon is. The audio path when using the app to Chromecast was the starting point of the thread, but LJS’s question on this was answered by Steve earlier in the thread. Then the discussion turned away from the app and to how the audio path is when using Roon. So, I think this is all fine and LJS had a legit question bout Roon that was nicely answered by Steve. LJS and I just have a different understanding of this answer.
No I don’t think so… LJS said the optimum SQ on the NDX2 was to use the Naim app… I was saying the app has no bearing on SQ… and in his example is moot, as the app can control Roon, Qobuz and UPnP… which I think is your view as well.
OK thanks As usual all you wrote about the app is spot on, I just think don’t think that LJS meant the app. But that would be for him to clarify. I am going by
I don’t think it’s about the app for LJS because in the linked thread he was completely aware of the fact that the app has no bearing. He was right too in the linked thread about the fact that even if the Qobuz app is not in the signal path either, streaming from the Qobuz app via Chromecast does trigger a different stack in the NDX2 , and there is a possible SQ effect by this, which was indeed confirmed by Steve in the middle of the old thread. This is all good.
I am convinced though that Steve did not say that Roon has a detrimental effect on SQ and that LJS is reading this wrongly. But I have said my part about this.
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.
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.
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…