Do you really want just the minimum? Why not just spend $100 more and get the I7?
I5:
I7:
Probably get at least 2 more years of useful life before obsolete out of the I7. So actually cheaper in the long run, and you get to enjoy more power the whole period of ownership.
The NUC7i7BNH is the fastest NUC officially supported by ROCK as of today. 4GB RAM is enough for about 10k albums or so… after 8GB, it won’t really make any difference.
The NUC7i7BNH can upsample TIDAL 44.1/16 to DSD512 at 1.8-2.0x real-time, with about 30% CPU utilization. This is more than comfortable for DSD512 upsampling, with the 2/3 of the machine sitting idle for other use. I just tested this on a NUC7i7BNH to a T+A DAC-8 DSD.
Now, the Intel 7700 and 8700 CPUs have more cores, but our DSD upsampler, when running in parallel mode (it’s an option you need to turn on), can only use up to 2 cores - so if you are only doing this upsampling on 1 zone, a quad-core machine won’t do it any better–it will just have extra cores sitting idle during the process. The NUC is more than sufficient.
Note that in terms of single core performance:
The 7700’s single-core performance is about 10% faster than the 7567u in the NUC.
The 8700’s single core performance is about 20% faster than the 7567u in the NUC.
However, they do so at a significantly higher TDP (65w vs 28w) and with very little value added.
There is a reason we chose the NUC7i3/NUC7i5/NUC7i7 line and that should be clear here.
I dabbled a bit with upsampling over the last few weeks – my NUC6i5 with Roon upsampling to DSD512 ran at about 1.4x real-time. Dangerously close to the critical threshold perhaps, but it ran just fine without as much as a hiccup.
Sure, but adding a convolution filter is not helped by adding more cores. Roon still processes the signal path using 2 cores at most.
I just added an Audeze preset to my DSD512 upsampling signal path (these use a convolution filter behind the scenes) – it made no substantial difference in CPU usage using the NUC. It is totally practical to combine convolution and DSD upsampling. In these cases, the convolution processing is happening at DXD (352.8kHz) anyways.
Your situation in the past was caused by processing DSD256 source material through a large convolution filter generated at a low sampling rate. This is a different from upsampling. In that situation, Roon was forced to upsample the filter by 64x, creating an absolutely massive load on the convolution engine. A long filter generated at low PCM sampling rates is not a good match for the “Native DSD Processing” option, and would struggle on any CPU.
Hey Danny, I’m impressed that you remembered that!
I generated the convolution filters using REW as per the instructions on this site, and am using Room to upsample, so I don’t think my situation is anything exceptional?
It’s exceptional because REW is incapable generating filters above 192kHz. REW’s authors were probably not thinking about DSD when baking in that limitation.
HQPlayer can brute-force its way through the problem with an expensive GPU + CUDA support
Some professional-grade software can generate filters natively at higher sampling rates, also
The problem is REW – you cant do everything with everything. If you want to do those DSD rates with REW, unfortunately, you will have to convert to PCM and back – that’s what the last sentence of my post was saying.
Thanks for your further insights Danny. You say that REW is the problem, though it seems that REW is the most popular software to generate these filters (on these forums at least). Maybe most people aren’t using it with higher res/DSD files.