Excellent - so confirmation from Naim (Steve) that Roon is bit perfect and natively optimised into the architecture hence the Roon Ready status … and indeed this aligned with earlier correspondence I have had from Naim.
Thought so… and sounds like it too.
I think LJS might have been confused with RAAT/UPNP Media transfer with Chromecast or AirPlay - or Roon Tested methods used for some other vendors by Roon ,
The application buffer aspect is for synchronisation and latency management NOT SQ - and therefore if playing Roon over a VPN or a mobile phone it may experience dropouts compared to the UPnP media transfer because the smaller buffer for Roon would otherwise be data starved… However i say 99.9% of people will use Roon on their home networks therefore this is moot.
Roon uses a separate server to buffer audio from remote services and NAS - as opposed to on the client - this keeps processing down to a minimum on the client therefore theoretically improving SQ on the client.
I agree and that’s what I meant. Maybe the way Steve worded it lead to an SQ expectation: “there are some small audio differences between the ‘UPnP’ route and Roon.”
I am quite sure what he was referring to was the audio path (as opposed to bookkeeping/protocol data) and not “audible”
yes see above - in theory if playing Qobuz for example Roon / RAAT would sound better than natively playing on the client - but I suspect such SQ advantages for Roon would be incredibly hard to notice in a blind test
this doesn’t mean that it’s worse. Different could theoretically even mean better, though that is not said either. I just think it’s unwise to ignore the preceding statement in the post that I mentioned,
Naim solutions are pretty sorted with Roon and nothing is crippled if playing via Roon.
But in the end you will have to clarify with Steve if you need to know for sure
Please read the full discussion I had with Steve. In it, he clearly states that the only way to get optimal sound quality out of the NDX2, is to use it natively (using the Naim control) app. All the other data path have some kind of sub-optimal element in it.
Why try to tongue-twist a clear statement from Naim?
That a thruth is inconvenient, does not make it wrong.
Indeed, and as I said if the UPnP is not transcoded or against a cloud FLAC stream, (like Tidal and Qobuz), then Roon should sound theoretically better on a Naim streamer…
But I think for the most part these benefits will be subtle, and to my ears Roon and local UPnP are pretty equivalent… although there is a very slight sonic shift between them… from a SQ perspective I would say they are identical…
I guess that is the sort of quality you are buying into when using a Naim streaming transport.
Bets are off with lesser makes and products.
I can also say the Naim app has no bearing on SQ… it is not part of the signal processing chain… I can only think you have mis understood Steve… and of course the Naim app can can control a Roon sequence list…
Really not sure why think Naim have sub optimally designed its streamers with respect to any source other than UPnP pull operation… thank goodness that is not the case as Naim wouldn’t have sold so many of them…
With first gen streamers there were small SQ differences between UPnP servers (inter frame timing consistency), but this was effectively eliminated with the new architecture… not least helped by the use of LVDS to isolate digital noise from data timing processing… I shared my info and traces on the subject with Naim when they were developing the new streaming architecture.
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.
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
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.
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