What @brian is saying is that the number is not designed for that purpose. Your conclusion is unwarranted.
I would also ask, what do you care how hard it is working?
Seems to me, there are two measurements that make sense:
Is the machine delivering the work you want? In this case, is it playing music without failing?
Second, if you are that guy, how much electrical power is it using? I don’t care, but if you do care, measure watts pulled from the wall.
I don’t think this is a correct statement; AFAIK, ROCK does contain Roon OS. There are some additional tweaks done for the Nucleus products for power management in the fanless case, and the addition of drivers for Home Automation systems, but for the rest, the OS in ROCK and the OS in a Nucleus is the same.
I recall reading someone finding that the performance indicator is low but becomes higher when Roon started to analyze the music - which is counter-intuitive. This is possible because in that particular setup, the OS chose to run the CPU at a low speed when it was not stressed.
So I’ll offer an alternative hypothesis (which may or may not be the truth): Roon OS may choose to run the CPU at a lower clock than Windows for the same signal path, seeing that it is already enough for playback, so there is no reason to use more power - which is especially important for Nucleus since it’s fanless.
I’ll propose that to evaluate speed based on the performance indicator, you need to do the most stressful DSP playback instead of an ordinary playback. That means multi-zone DSP + DSD/PCM conversions. But ultimately, it is not a good enough indicator for comparative evaluation - to quote Brian:
The processing speed indicator is influenced by too many outside factors to really use it for that purpose. It’s there to tell you if you’re “safe” or not. That’s it.
I care if the performance I see is worse on ROCK because of ‘what if’ scenarios, like I decide to do room correction in the future, or add more zones etc. All indications are that ROCK is not performing as well in this area as windows was which is disappointing given it’s intended purpose.
I may very well do that.
That is an interesting suggestion. I will try and max it out. But I’ll have to go back to windows to test it there as well. I only have figures for my normal signal path performance on both platforms.
Yes I have seen your thread but in that case the hardware is entirely different. All the factors outlined by the others posts in this thread then apply.
In my case everything is absolutely identical so there is far less to explain the difference.
I would also say that I haven’t noticed any issue with the UI performance in general as you have. My only issues are the rendering performance and slower start up when playing tidal content.
You’re right, I’d misread a post some time back. Here’s the lowdown:
I’m sure you’ve already checked but it’s worth making sure that any ‘Green Energy’ settings are turned off or disabled as we’ve had major ethernet speed issues with some PC hardware when it was left in the factory enabled state.
OP, what have you got the Rock configured for DNS?
It is set to 8.8.8.8 now which has improved the tidal problem a bit
And this is the crux of the issue. Not whether apples vs. oranges are being compared or how the performance indicator is being computed.
Try cloudfare as well. 1.1.1.1
I agree but how to actually know for sure ? Given the restrictions in ROCK the signal path performance is the only way.
To be perfectly honest I’m not that bothered about it, except in that it is an interesting difference when you consider the 1.7 release notes claim.
Maybe Roon would be interested in finding out why this difference exists? It might be an issue that could improve ROCK performance further, or it might be nothing. I’m happy to work through some tests if anyone from Roon is interested.
The release notes also talk about improved buffer handling and I’ve noticed a couple of artifacts that might be buffer related and that I didn’t have in V1.6.
So it goes.
The release note is solely about performance gain for the library management aspects of Roon.
They certainly call that out specifically but the rest reads as a general claim that RoonOS will perform better across the board than the alternatives. At least it does to me.
Hello to all
think that the problem is up in win 10 cpu core management vs Roon Rock core management, win 10 is Maybe Better to address the core load to 2 cores in the 8i3beh, in my 7i7bnh there is no problem with anything, regardless of dsp .sice of library wifi 6tb music on nas. Tidal ect.
Happy new year
Yes this occurred to me too. I don’t know what Linux kernel ROCK uses but maybe it’s thread scheduling is less efficient than the latest windows 10 kernel.
I suspect the only way you can directly compare the platforms is to put them under such a load as to max out the CPUs - several zones running heavy DSP, upsampling/DSD conversion etc.
Ironically a more power efficient OS might actually report lower performance when not stressed because it slows everything down more to conserve power.
I used to get this misleading comparison between OSX and Windows long ago when I was comparing the platforms (on the same MacBook pro) for running Ableton Live (an audio workstation app). It was only when I really stressed everything to force maximum CPU use did I start to really see one of the platforms (OSX) start to pull ahead in terms of being able to deliver glitch free low latency multi-channel audio. Often before that I was seeing apparently lower indicated performance on OSX. Ableton live uses a similar mechanism to Roon to indicate the ability to process a workload - ie how long did it take to process the workload vs the time is absolutely must process the workload in, but expressed as a percentage instead of multiplication factor - effectively the inverse of the way Roon indicates this.
Also, while the main server app and its network protocols appear to be written in .NET, this is probably not the case for DSP and low level audio processing and the RAAT protocol, so while I may expect a more responsive server for searches,network control protocol handling etc (ie what the UI controller apps use to communicate with the core), the migration to MS .NET runtime may not impact audio processing much if at all if those parts are written in C++ as I might expect with .NET code being used to basically just orchestrate them.