So a Ryzen with 8 cores and 16 threads is total overkill since at most roon spreads the load over 2 cores? Those cores benefit HQP.
Your skepticism is warranted.
For DSD, why even DSD256, let alone DSD512? Only DSD64 faces some debatable noise shaping and low pass filtering issues just above the audio band. By DSD128, those concerns have been rendered irrelevant.
High end D/A conversion long since has veered into the realm of “if possible, then necessary.”
Hey Slim, is your background audio analysis still going? And at full throttle?
My old fanless sonicTransporter i7 doesn’t break a sweat with DSD512 so I can highly recommend that. I’ve since given it to my old man (my dad) since I’m only using one zone now and I’ve setup multi zone for him and it does DSD512 and other stuff quite easily in his setup.
Can you tell me, what is the benefit of DSD512?
I’m not really a technical or measurements guy. I prefer to trust my ears, having owned a DirectStream and Playback Designs and Hugo 2 DAC (all 3 have FPGA’s that up-sample to super high sample rates, way beyond DSD512).
But for those that love measurements, here are some by HQ Player’s Jussi with his iFi iDSD:
With the iFi DAC that I bought my old man, it did sound best going to the DAC’s maximum supported DSD sample rate and that was even before I knew Jussi had done some measurements.
The majority of systems used to run Roon have 2 cores / 4 threads or less. NUCs are the typical archetype. We monitor these stats on an ongoing basis to drive these decisions.
There is overhead associated to splitting/joining work across cores. It is most efficient to run things on 1 core if they fit there. We enabled the split to 2 cores as a technique for making extreme DSD upsampling cases workable.
Unnecessary multi-core processing has other have negative consequences for the overall user experience. You want cores sitting relatively idle at all times so that when you load screens/search/focus, power up a remote, or kick off radio playback the capacity is there to quickly do the necessary burst of processing immediately.
No, that’s inaccurate. Roon uses more than 2 cores in a lot of ways…Roon uses at most 2 cores to handle audio processing for a single zone.
Library management happens on a separate thread, too. So does the UI. So does each folder you are watching. There’s a separate thread that handles communication with remotes, and zone management in the core too. Audio analysis can use all of the cores in your machine if you configure it to.
Plus, the vast majority of Roon users have multiple zones, which then spread their combined load across more than 2 cores.
Roon is balancing all of these needs (plus more I’m surely not thinking of)–there are lots of separate components which need their performance to be relatively decoupled. HQPlayer is a single zone product. Its job is to take over your whole machine to run one zone–we would be shooting ourselves in the foot if we viewed the problem that way.
In terms of future multi-core scaling improvements–
I would much sooner sink resources into making library and database management more parallel than just about any other part of the system, since this is where the most severe performance bottlenecks in the product live.
The most efficient avenues for improving DSP performance are still in the single-core domain–faster SDM’s, faster SRC, faster IIR filters. Responsible optimization efforts focus on the lower-hanging fruit first before spending big on architectural changes.
Hitting more extreme multichannel targets is interesting–but keep in mind that the great majority of multichannel systems in use with Roon are based on HDMI, and thus running at no higher than 192kHz, so they don’t present a severe performance demand. A small handful of people have access to ultra-high-rate DSD DACs like those from exaSound and Merging. They create more intense performance constraints when you want to turn the DSP knobs way up. HQPlayer remains an option for squeezing out more from extreme hardware configurations.
Intel NUC with ROCK processor advice
Greetings, brother. Long time.
Yeah, but I have 8 cores and if Roon only uses 2 cores per zone for upsampling, then I should be all right.
Still easy enough to check. I’ll get back to you.
Greetings Slim ! Long time indeed. Did we tempt you into an iFi iGalvanic3.0 yet The dark side is always here to help
Only reason I ask about the background audio analysis (not ‘on demand analysis’ was when I had it on “Fast”, since it chews quite a bit of CPU, then when I was doing DSD512 up-sampling the processing rate would drop quite a bit.
But when I had background audio analysis on “Throttle” or when it was complete, then the processing rate was never an issue with DSD512.
It just came to mind so maybe something to double check.
Definitely going to try turning off background analysis.
Turned off background audio analysis. Didn’t make a difference, processing speed was still 0.8.
Nice try, but I guess the answer is an i7. That’s alright, I’ve got an empty motherboard w/ram and in a case. All I need is the CPU.
I tried tonight and I could run DSD256 with convolution, processing speed was around 2. I don’t know how to test DSD512 since I don’t have that option to up-sample to.
Ah damn. Was hoping that would allow you to creep up to the safe zone processing speed, x1.3
Let us know how the i7 build goes.
PS: the next gen iFi DACs will support DSD1024 I hear. I wonder what kind of horsepower that will need, if/when Roon supports it. Assuming double the CPU usage of DSD512.
Is this with the S2? If so, I thought that was good for DSD512.
I have an i7 7700 in my Roon server and it runs all Roon filters upsampling to DSD 512 plus room EQ without an issue. It also runs all HQ Player filters upsampling to DSD 51 plus room EQ save for the xtr filters. With those I have to use the xtr-2s variants that do it in two passes.
I can also use a CUDA capable NVidia GTX 970 GPU with HQ Player but it doesn’t change the above, just lowers the CPU load and temperature.
Lately I’ve been listening more to PCM upsampled to 705.6 kHz with the HQP xtr filter. I think I may prefer it to DSD 512 as it has a better attack.
I think it is, @gahabana had got it working, but DSD512 does not work directly from Roon as far as I can see. I haven’t bothered to investigate myself, since it takes to much CPU to be practical for me (I use DSD128 right now, which have processing speed 8 with convolution filter and PEQ house curve).
FYI - I have an iFi iDSD DAC which is DSD512 capable and Roon lets me select DSD512 in it’s DSP settings.
You should also see DSD512 for your S2. If you don’t want to run DSD512, then it’s only important because it may indicate, yet again, another problem with S2.
But, good for you, good for me.
hi @Slim_Fishguttz, all good. S2 works perfectly well if DSD512 is what you want/need.
As I am not using Windows as my roon endpoint but linux so same as with Oppo Sonica DAC or W4S DAC-2v2SE or Marantz’s and Dennon’s and MSB’s and Deneris etc linux kernel (which contains the driver) has to be updated to recognise beyond PCM768k and DSD256.
Once that is done and I assume @brian and team could do that on ROCK easily - S2 will show also DSD512 and ‘native DSD’ mode.
I think Linux Kernel for some/most iFi devices has already been updated while ago so those devices show up by default as DSD512 capable (when they are).
I had a feeling it was because of drivers, can something similar be done on Windows, or does Pro-Ject has to update the drivers that came with the DAC?
I’ve modified the post above from @andybob to have a link to his cpu… the problem here is your CPU, which needs to be faster.
@brian has commented on multicore usage in Roon, and the differences in strategies between HQPlayer and Roon as well.
I’ve also cleaned out some antagonistic posts from the thread…
I’m not sure this thread can provide any more useful information, so I’m closing it out.