Yes, it will make a difference. NUC10i7 is the single worst NUC to run Roon on - it has 6 super slow cores.
Since Roon runs on a single core for sound quality reasons, to make it work faster you need a higher clock speed, not more cores (as they will sit basicly unused anyway).
NUC 11i7 ditches 2 cores (has only 4 compared to 6 on the 10i7), but goes for the much needed higher core speed.
Roon performance index (with upsampling to DSD64 switched on) for those NUC is as follows:
Roon doesn’t parallelize to keep the code simple. It has nothing to do with sound quality. It can however use one core per channel, so for stereo, it can use 2 cores. And if you stream to 2 rooms simultaneously, it can use 4 cores etc. Of course, this only matters if you use DSP.
Whilst I agree that the 4-core NUC can support heavier DSP and your statement is almost certainly correct in the context of this thread (we don’t have quite enough information to be absolutely sure) and is probably true most of the time, it may be a bit too general.
Anyone that uses more than 4 endpoints simultaneously but with intermediate DSP (such that the NUC10i7 is just adequate) on all endpoints may be better off with the NUC with more cores. Accepted, non-streaming performance (for e.g. search) may suffer as a consequence of the lower single core performance but ‘slow’ is still better than ‘can’t do what I want’.
Granted, this use case is probably not that common. It is certainly far removed from my own (maximum of three endpoints in use at any given time and only very moderate DSP and only then on a couple of the endpoints). However we should be careful using blanket statements.
Torben_Rick
(Torben - A Dane living in Hamburg - Roon Lifer)
26
Yes But what if you using convolution and sample rate conversion?
That is true to processing a single stream during playback. But is this also applicable to computing intense database operations when browsing, clicking from one composition list to another?
I tried to monitor the single core usage of my quad core CPU over time, and had the feeling that mostly 2 cores are involved while performing such operations with 1 core sometimes spiking and subsequently handing over to another. While using focus, filters, coverflow and similar operations it seems to be even all 4 at a time. Text search itself btw seems not to be CPU-intense.
That is true Roon will use more cores for initial library scan and when playing simultanously to multiple zones with DSP enabled.
The question is: how many ppl will use it this way? Probably less than 0.01% of Roon users.
And even in those rare cases, 4 physical cores (which translate to 8 logical cores) is still all you will ever need. Getting two extra cores at an expense of core clock speed, just makes no sense.
Torben_Rick
(Torben - A Dane living in Hamburg - Roon Lifer)
31
THX - But do you see which Intel 13 i7 has 4 physical cores (which translate to 8 logical cores)?
Every single one used on NUCs up to 12gen. It is called hyperthreading. This is why 4-core CPU shows up in Roon as having 8 cores.
Various Celeron and Pentium CPUs on the other hand do not have this feature. That is why when you install Roon on sth like J5040 (which is the CPU used in all 432 Evo servers, Iden AbsoluteStream an others), 4 cores show as … 4 cores.
13-gen NUCs are a bit different, as only performance cores have hyperthreading.
It depends what kind of PSU are you gonna use. 13i7 current draw is so high, that it will crash on most audiophile PSUs.
This is the reason it comes with 120W PSU stock and have additional cooling on coils (sth that was absent on NUCs up to 10th gen). To give you a better idea how much current that is - 120W at 12V equals is 10A (!). Most audiophile PSUs can deliver up to 3A @ 12V. SBooster - which is an excellent PSU - maxes out a 2.5A for example. Both 11i7 and 13i7 spike more that that even during startup.
IMO the best all out NUC right now is 11i5 - very close in performance to 11i7 (also 4-cores, just 100MHz less CPU clock speed in turbo mode), does not have such a big current spike at startup.
Throw in 16GB of dual chanel RAM and a fast NVMe SSD and you will be all set.
That said - if you have an Roon Ready DAC which is connected to your Roon Core via Ethernet not USB and you can place the NUC away (say in other room, garage etc - somwhere where the fan noise will not bother you) you can get the 13i7 and stick with the stock 120W PSU.
Thanks for the insides and your estimation. That absolutely makes sense in my understanding and is matching with my experience so far. The best roon experience I ever had from a standalone unit was based on an i5 Gen10 or i5 Gen 11 Quad-Core CPU. It was so reactive and snappy that even browsing experience on a Nucleus+ in direct comparison felt slightly delayed.
Another quick question - perhaps a silly idea, but I know I’ll get an answer here. Will the NUC 10 or 11, neither of which comes with 2.5 GIG ethernet, be able to use a USB C to 2.5G ethernet adapter? If so, would that be worth the relatively small investment? (Yes, I have 2 GIG fiber.)
Well, I tried two of these adapters and plugged them in at the USB C and then (with yet another adapter) the USB 3.0 ports. Looks like these are not “plug and play” with ROCK, and I have no idea how to add (or even if you can add) drivers to the ROCK. Was worth a try, and it’s easy to return them.
I don’t know how Roon’s code works, but parallelizing convolution and rate conversion makes sense even though the output of convolution is the input to rate conversion. It’s not a given that Roon uses only one thread per audio channel.
For simplicity, assume it takes one time unit (t) to convolve a block and it also takes one time unit (t) to convert a block after it has been convolved.
If there are n blocks, and the code is written to convolve a block, convert that block, move to the next block all on a single thread, the total time to process a track will be 2n * t, or just 2n for simplicity.
If, however, you use one thread to convolve, and another to convert, the total time will be n + 1. In other words, each time the convolution thread finishes a block, it hands it to the convert thread and immediately starts convolving the next block.
Assuming that convolving a block and converting a block are atomic, the theoretical best time for this operation is the fixed time of 2t. That requires as many threads as blocks, though
I think it is, based on what they’ve said on this forum. Unless it uses one thread per stream, which is worse.
I agree that you can parallelize the DSP pipeline that way, but as far as I know, parallelization works within one block, many times at sample level. This means that you can use all cores while processing one block in one step, so you still take full advantage of CPU/GPU, even if you process steps sequentially.
Anyway, since Roon doesn’t parallelize anything within one channel, it doesn’t really matter.
But what if you using convolution and sample rate conversion?