I have Roon/ROCK running on a NUC8I7BEH1. It’s a quad core processor that runs at 2.6GHz, and 4.5GHz turbo. The NUC7i7BNH runs at 3.5GHz and at 4.0GHz turbo. It’s been noted that a NUC7i7BNH can upsample Tidal 44.1/16 to DSD512 at 1.8-2.0x at 30% CPU utilization. That should mean the same process should run 30% slower on the NUC8I7BEH1. The NUC8I7BEH1 can’t seem to keep up with upsampling DSD512. DSD128 works. Do by any know why? (It seems that it should keep up…)
Not sure where “it has been noted”, but, there are a lot of variables that factor in.
In your screen pic, you are running at a better rate than the rates you quoted for the other NUC. The lower the processing speed the higher the actual core processing, so 2.5x means you are using 40% of 1 core to process the DSP, where 1.8x means 55.6% core usage.
Generally speaking, if you are above 2x, then processing shouldn’t be a limiting factor. (Unless you are also doing something like audio analysis with a new library at the same time).
You did not describe the symptoms except “cannot keep up”. I don’t know what you mean by that. Are you getting skipping? How is the G2 getting the audio stream, is it connected via USB, over the network?
Also, have you enabled this? Try it and see if it helps.
roon processes audio on only one core. so, processor cores with a higher base speed will perform better in terms of processing speed. in your example the NUC7i7 @ 3.5 gHz will outperform the NUC8i7 @ 2.6 gHz by a significant margin.
one suggestion that might get you DSD512 on the NUC8i7 is to enable multi-core processing for DPS / DSD as follows:
I was referring to Danny comment on the forum.
When I play at DSD512, I get the message “Audio file is loading slowly”. It then stops and moves to the next song. The fan in the NUC is also running.
The DSP Configuration is as follows:
on thing to investigate: since the fan is running, it might be possible that in up-sampling to DSD512 the processor is generating enough heat such that it is being throttled?
seems unlikely since intel lists the processor TDP of that NUC as only 28W – but thought i would just mention it in case
How are you connecting the G2, is it plugged into the NUC, over the network.
Also, where is the file you are playing located? Is it local to the NUC or elsewhere on the network?
The G2 is plugged into the network through a etherREGAN which in turn connected to connected to a sonore opticalModule. The interface to the network is Orbi Wireless LAN. At the Orbi, I measure 31.8 Mbps out the Internet. The Orbing is capable of transferring over 800Mbps. If I’m not mistaken, 24Mbps should be all that is required. I get the same error if I go above DSD128. The file is located on the NUC.
Your processing speed looks ok. Try bypassing the G2 and direct connect the DAC to the NUC via USB.
WiFi bandwidth figures are often not useful for real time requirements of audio.
The bandwidth of the Orbi is well over 200Mbps. If I connect two devices via 5Ghz, I measure more than 500 Mbps. If my math is correct, we only need 24Mbps for DSD512. (Correct if I’m wrong) I have used a 4K television (which needs 32Mbps) on the interface and have no problems. The fact that the fan runs in the NUC is telling me it’s an issue with the NUC.
Then prove it by direct connecting the DAC.
but the single thread ratings do not support this view.
I don’t understand your comment… are you saying that a 3.5Ghz processor running single threaded won’t run faster than one that is running at 2.7Ghz single threaded?
1 Like
These single threaded benchmarks are obviously running in Turbo mode. That is a special case. We’re using two core when decoding.
OK… I tried bypassing the optical module and the etherREGEN… and didn’t have the issue. I then tried the ethrREGEN and still no problem. Once I installed the Sonore Optical Module I had the problem. It is the new Sonore opticalModule Deluxe module. I’m going to talk to Sonore tomorrow. Please let me know if anyone else is using this module.
I get this message when I upsample to DSD64 using a Nucleus+. Processing speed is 10.4x but I don’t get many drop outs and don’t get the message all the time. Your processing speed for DSD512 looks pretty good.
assuming passMark software tests performance at base clock speed, i stand corrected.
however, i suspect that in order to do such testing the turbo-boost would have to be manually disabled by the user – unlikely in their crowd-sourced sample set. otherwise, it is dynamically engaged for heavy workloads.
that being said, i will happily defer to those with greater technical understanding and experience.
~ 
note: with constrained thermal management capabilities such as a passively cooled chassis, higher base clock speeds are important – given the same TDP.
let us know how this resolves – i have been considering the use of a sonore opticalRendu.
also, it might be useful to keep the optical module in the system and bypass just the etherREGEN. if this causes the same problem then it would certainly be the OM …otherwise, there is possibly some issue with the OM → etherREGEN connection.
I wish there a way to go with just the OM and bypass the eR, but I can’t. I depend on the optical connection on the eR.I suspect that flow control on the OM hasn’t been properly implemented. I wish the Roon had some way to see the errors that it was receiving. The fan in the NUC only comes on when it encounters the errors, so Roon is definitely receiving errors from the connection.
ahhh, yes …if you get desperate, you can always get a simple FMC to further troubleshoot. i use one from fs.com and it has worked flawlessly – although i have not tested it w/ DSD512