My comment was moved. The information that I posted was related and a response to the new Titan. Someone mentioned that the Titan looks like a NUC 13.
Doesn’t bother me, but I didn’t understand why the post was redirected to this thread.
Regards,
Tony
While no big deal to me, I can say that the moving was not done with a great deal of care as many Titan relevant posts got swept up into the purge, including mine.
One idea would be to simply remove argumentative or combative posts entirely, rather than end up with a mishmash of what was moved and what was left alone in terms of relevance. For better or worse, the Hoffman Forums are swift to delete arguments entirely.
What is the best nuc 13 for roon
I3 or i5 or i7
?
If you want to use ROCK the 13th generation are not currently supported.
If Titan is really based on a 13th generation, then support may be on the way.
If you want to buy now, and want to use ROCK, you should buy a 11th of 12th generation.
ROCK doesn’t (yet) support audio over HDMI on the 12th generation, so if that matters buy an 11th generation.
Which CPU you need depends on your library size, and how much DSP you use.
Roon’s advice is here: https://help.roonlabs.com/portal/en/kb/articles/roon-optimized-core-kit
I have 305k
Currently using nuc8i7 which is slow
I read that single processor speed is essential - so i5 would be better than i7
300k is a very large library.
There have been a few threads about optimising performance for very large libraries (although some are quite old so perhaps start another).
The 8i7 is a pretty fast NUC - I doubt a newer NUC would help much.
More memory and the fastest SSD in your 8i7 might.
Some have switched to desktop machines with hotter desktop cpus with better cooling (NUCs use laptop cpus).
I have doubts about this statement, which is widely used here in the forum.
I followed the way Roon uses the processors, with the observation that I don’t use DSP (only volume leveling sometimes).
I saw that Roon uses 1 processor for audio (or 1 processor per DAC). However, the required computing power is very small (at least in the way I use it).
However, when it comes to all other activities of Roon (starting the server, backup, album identification, audio analysis, search etc.), i.e. exactly all those related to responsiveness, Roon uses all available processors. Also, the required computing power is very high.
Maybe having powerful cores (fewer and powerful) is important if you use massive DSP. Otherwise, I think it is not important.
On the other hand, for system responsiveness, I think it is much better if you have more cores.
As you say it probably varies by use.
Because roon uses a single core per endpoint for DSP (with the exception of DSD upsamping which can be split across two cores) - some people can run into single core limits.
DSD upsampling can take a lot of CPU - so it generally makes sense to have as powerful single core as you can manage.
Thanks 
But what is currently the most powerful single core?
Torben
In NUCs?
Not sure. For a while it was the 8i7. Don’t know if this is still the case.
But think the differences are marginal.
More modern cpus are generally scaling out (more cores) rather than up (more clock speed).
I think the latest is Core i9-14900KF or Core i9-14900KS both top at 6.0 GHz out of the box with no overclocking. Neither would be in a NUC as they are desktop CPUs, and NUCs mainly use mobile/laptop CPUs.
This is true but each generation of cpu tends to offer higher instructions per clock so a Gen 12 core may still offer better performance than a Gen 8 core clocked at the same speed. This is not universally true but it has been the case for a number of the generations between 8 and 13 (if not 14). Thus I would expect my 11th gen NUC to perform better than an 8th Gen NUC clocked at the same rate.
For 12th generation upwards, we also have the introduction of the big-little architecture to confuse things (ie performance cores and efficiency cores).
Unfortunately, this makes trying to determine the cpu with the best performance across generations somewhat difficult.
You could always look it up here:
Comparison Charts for Intel® Core™ Desktop Processor Family
I use several outdated iPads as zone displays with firefox klar. Works well, only thing I would like to disappear is the status bar of the browser. No luck though.
Roon utilizes one core most of the time, or so I have learned. To make it perform better one would need to do changes to the way roon uses those cores. Roon does not do this.
1 core > 12 core = x12, 3 GHz > 6 Hz = x2. That simple.
Using multiple cores would also benefit process isolation, ie. the software would be usable for the enduser although there is (heavy) load in the backend.
Don’t know what version iPad OS you’ve got, but there should be free of charge Kiosk browsers to fix you up!
It’s never that simple. Changing an algorithm that only uses one core (single threaded) to an algorithm that uses multiple cores (multi-threaded) always uses more cpu resource in total.
3GHz → 6GHz will give a x2 performance increase only if all other limiting aspects of the processor architecture are scaled to match - for example memory bandwidth. If the application is memory limited at 3GHz, changing to a 6GHz processor without changing the memory architecture will not improve performance. This is one reason why desktop processors are typically much higher performance for some applications despite having only a 40-60% clock advantage over a laptop processor of the same generation. Desktop processors typically have dramatically higher memory bandwidth (and dramatically higher power consumption as a consequence).
1 core → 12 core will not give a 12 x performance increase except in the most trivial cases because:
Since an effective multi-core algorithm is also much more difficult to design, implement and maintain, the main motivation for moving to a multi-core algorithm is to enable more processing to be done before a deadline - which roon already do for DSD upsampling.
In some (many) applications, there are other motivations - such as GUI/control/input responsiveness but it always comes at a cost in terms of total resources used and maintainability. Roon server, as it stands at present anyway, already divides tasks between cores to satisfy this apsect - background library and database handling does not, typically, happen on the same core as the endpoint handling - although, obviously, it can do in extreme cases.
Also, Roon doesn’t utilise one core most of the time, it utilises one core per endpoint in use most of the time so if you have a four core processor and four endpoints in use, all cores will likely be used.
Before you can say whether Roon would be improved (or not) by changing to use a multi-core approach to endpoint streaming, you have to take into account all use-cases - and consider how the chosen approach can accomodate them and what the development cost of such a software architecture would be. It could be that what is advantageous for one use-case (1 endpoint in use with very high DSP) would seriously degrade the performance for other use-cases (multiple endpoints in use with moderate to high DSP).
As it is, the current Roon approach works without demanding extreme high performance processors for the majority of people - probably a considerable majority.
Well put, Wade. However there are some people that are not most people whose systems would benefit. Looking at all those complaints about sluggish search and user interface in general (plus playback stopping and or being delayed for no reason at all) I think seperating streaming, frontend and backend would be a step forward.
I believe that that is already done to some extent. The streaming is separated out from the user input handling/search and background analysis.
However, it also has to be said that the experience of slow search under some conditions is not universal and some people (like myself) with moderate server platforms do not suffer many of the problems that others do (I can’t speak to all use cases - because there are some that would be far to intrusive to my system for me to attempt to replicate - but, for those examples that I have been able to replicate, the performance on my system has been entirely acceptable). As a consequence, I think it is fair to say that there is probably a lot more to these issues than simply suggesting that more cores should be utilised to accelerate processing.
I am really happy to hear that you are really happy with what you got.
Core utilization vs. speed was just a side note. Roon is targeted a small to medium size collections, and not many thoughts seem to have been spent on scalability. This is why it falters once a given size is reached. Multicore would not put an end to these problems, just put them farther away.