Wow, a lot of passionate discussions here. I remember car radio ux used to create a lot of debate and it still does to a lesser extent since we have such as apple carplay and android auto. Then we just rely on the apps built by the streaming / media platform with all the supported fantastic meta data and features of each. Naim focuses on SQ and provide the ability to integrate with a nice flexible controls and interface making it easy to integrate (such as touch screen).
Really, have you a reference from Naim engineering or product design… I have not experienced that using the Naim default Roon settings for a Naim player… and Roon provides transcoded PCM transfers, like UPnP when transcoding is enabled.
In fact Roon provides certain key performance benefits over regular UPnP such as high bandwidth with 32 bit samples… of course whether you hear these SQ benefits will be down to environment and listener and media… as always.
It was a concern for me too, especially as I am otherwise very much a free / open source software person. But I rip the CDs with dbPoweramp, so I am not worse off. Even if you rip directly with Roon, it first creates basic filenames, but there is an export option that puts covers and other stuff incl. edits you made into the files and names them properly:
And I am so happy with it that I purchased a lifetime license and a fancy fanless NUC as a server. There is nothing comparable in the market place as far as I am aware, I am not going anywhere, and I very much hope they don’t either
I see. Yeah that’s better, but my reply was specifically to “if you rip or download to something like a NAS and edit the metadata carefully”. Like I admitted, I know nothing about the Naim servers,
I guess the Naim servers like Core might get some of this info from Rovi? Don’t know, never used one.
Do you have a link? Thanks. Like Simon I am intrigued because it’s just PCM, and I don’t think I hear any difference
Yes, it’s was a clear statement by the Naim SW director in this forum. If you don’t believe me, you can search for it.
Are you referring to this?
“As for sound it does go via a different stack and there are some small audio differences between the ‘UPnP’ route and Roon. The key difference is that when using Roon it doesn’t use the large 50MB audio buffer, so its always streaming from the server through the length of the track, rather than playing only from RAM. That is a design decision of the Roon RAAT implementation as delivered by Roon.”
Thanks. I added the link to Steve’s post with the answer for @LJS below, because it contains this statement right before your quote starts:
Naim solutions are pretty sorted with Roon and nothing is crippled if playing via Roon.
(and I saw and considered this before deciding for Roon, so it was very helpful for me that the question was asked - I am a bit surprised that LJS and I are interpreting the answer so differently )
As I have a direct (just via EE 8Switch) wired ethernet from the dedicated Roon server to the NDX2, with minimal latency and the max 100 Mbit/s bandwidth that the NDX2 provides, I would assume that surely the avoidance of the large 50 MB buffer is not an issue.
— ndx2.fritz.box ping statistics —
39 packets transmitted, 39 received, 0% packet loss, time 38052ms
rtt min/avg/max/mdev = 2.423/4.709/7.771/1.316 ms
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
Agreed again - and I cannot see a reason for the alleged disadvantages
indeed and only possible SQ advantages for Roon on a home network with a Naim streamer
To me, this is the main part of that post! There IS a different SW stack in use on the NDX2 when using ROON.
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.
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.