“When you Chromecast all that the mobile device does is to instruct the player to play a certain track”
Exactly. Same goes for the Naim app. That is the control path.
But my question is: is the data fetched from the source in exactly the same way, whether the command came in from the Naim app, or via Chromecast from the Qobuz app? And does it follow the exact same route through the NDX2? In other words: is the data path exactly the same?
Only people with intimate knowledge of the internal HW and SW architecture of the NDX2 will be able to answer this.
Thanks to all the other people trying to provide extra information, but your good intentions only lead to thread drift.
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.
For this reason + others, earlier this year we integrated Qobuz natively into the platform.
Proper buffering - We buffer up to 50MB of data at a time so very robust from internet data fluctuations. The average 16/44.1kHz track is fully loaded within 15secs, hence its playback from RAM buffer.
Efficient - near enough the same as playing a native 192kHz FLAC file from a NAS.
Faster to connect / play / do stuff.
Runs from the internal streamers Play Queue. Once the app has loaded in the play queue the streamer just gets on with it independent from the app / things in the cloud etc.
Overall, I would recommend use Qobuz via the Naim app if possible.
@Stevesky, thank you for this very complete answer. I understand the data path is different. With Qobuz + Chromecast, the Chromecast stack is used to retrieve the data from the network source. With the Naim app, the NDX internal streamers Play Queue is used to retrieve the data from the source. As such your recommendation makes sense, a lot of sense.
To bad that when using Chromecast, the internal streamers’ Play Queue was not used.
May I suggest that some of the usability issues, in which the Qobuz app is superior to the Naim app, would go away.be adressed in future releases of the Naim app ? Then this dillema would go away.
Forgive me for being forward, but I really wonder why is someone buying such an expensive piece of equipment, to then wonder only how such astream is (technically) handled in the equipment. Wouldn’t this be audible? Put on your favorite piece of music on, and a/b the two different options. And then enlighten us (the other forum members) with your newfound discoveries, instead of asking repeatedly some detailed question, and than insisting that the builder of the equipment must alter it. Why not caring what ‘sounds’ best?
Very interesting to learn about these technical aspects. Now that Jan got his answer, I’ll ask a technical question. I’m using Roon (with a small bridge) to access Qobuz on my NDS, how does it compare with Qobuz native on the new streamers? Is there also a stack or is Roon taking care of all these things?
I hope that your question will be answered but until then you could perhaps try to set up careful experiments to see whether you can assess differences that would imply a negative answer. What about gapless replay? Is it granted via both the Qobuz app and the Naim app? If not, the answer would be obvious. Can you shut down Chromecast on the NDX2? If you can and streaming via the Naim app still works, then you know the answer. What if you try to replay two different streams at the same time via the Qobuz app and via the Naim app?
You could also try to get in touch with the developer of upmpdcli (https://www.lesbonscomptes.com/upmpdcli/) and ask him: he is very supportive and used to provide a native interface to Qobuz within upmpdcli like Naim does. Another place where you could ask is at Bubblesoft: they should know quite well!
I am not sure that the OP was interested in which path sounds best, I understand that the original question was whether the data paths are the same or not. The question is interesting by itself, I believe, independently of sound quality issues.
Roon has its own buffer, and decompresses the incoming Qobuz FLAC stream to PCM, which it sends to the streamer exactly as it would if it was streaming from a local store on your home network. So it’s different again to native Qobuz or Chromecast.
Partly correct, I believe.
Roon runs its core on a separate server (see the Roon website - how it works - for more information). The core retrieves the data from the source, and buffers it. Roon has the capability to “treat” the incoming data (such as first unfold for MQA, or even transcode completely) before sending in on to the Roon-ready “Audio Device”. I have no idea which communication stacks the core uses (and I assume it depends on the actual server on which it runs). But i do believe it is safe to assume that it may not be exactly the same communication stack as if it was streaming from a local store on your home network.
In our case, the “audio device” is the Naim box. It receives its data from the Roon Core using its Roon client. It would be interesting to hear from @Stevesky, whether the implementation (communication stack) of “Roon Ready” and the internal streamer play queue are similar or different.
How good this all works, is also dependent on the performance of your Roon Core. I tried it out, and on my particular test installation on my daily use PC, it turned out that heavy CPU or network loads other then the core, could apparently introduce problems (cut-out). I assume that if you buy a Nucleus from Roon, or provide a dedicated/proficient server in any other manner, that issue would go away.
Again, it would be interesting to hear from @Stevesky what implementation issues in the communication between the Roon core and the NDX2, might impact sound quality.
Regarding Roon, the playback client uses the Roon RAAT service to natively interact with the Roon server. This is officially the ‘Roon Ready’ status and not to be confused on various other methods Roon have done (Roon Tested) to play to other product types (eg. Chromecast, Airplay, Linn’s own protocols etc).
In the RAAT service we declare the native capabilities of the product and then the server side aims to send the audio in the most native and bit perfect way possible (in LPCM or DSD stream). For example an NDX2 declaresL PCM up to 384kHz, 32bit and DSD64 and DSD128. Naim solutions are pretty sorted with Roon and nothing is crippled if playing via Roon.
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.