I’m currently using a MacBook Air via WiFi as my Core device. This computer is up on a closet shelf and Roon is the only thing it’s being used for. The only reason I ever have to touch it is to occasionally update the OS.
My question is about sound quality. If I were to plug a ROCK directly into the back of my streamer (Lumin D2), would there be an improvement in SQ, or would the sound quality stay pretty much the same.
BTW, thanks for all the help I’ve already received from this forum. 
It will stay the same, but consume a lot less power.
ROCK will have lower noise output compared to a typical PC/MAC because It has far fewer threads running on the background in the OS.
If you are using Lumin D2 as an endpoint then it makes less a difference if it connected via WIFI network. However if you connect directly to a USB-DAC then ROCK intrinsic low noise will definitely improve the SQ.
The other way is to invest on USB galvanic isolatior normally known as USB Regen; this helps to prevent the likelihood of noisy source such PC/MAC from reaching to the DAC.
To clarify, my Lumin D2 is hard wired to my router via an ethernet cable. The MacBook is connected my WiFi network. I was thinking that if I did switch to the ROCK, I would unplug the ethernet cable from the back of the streamer and plug it into the ROCK and then run a short ethernet (or ?) jumper from the Rock to the D2.
I don’t know if this setup is even possible because I just noticed that the NUC only has one ethernet port.
You would need to purchase a USB Ethernet adapter for the NUC and then configure the link between the D2 and the NUC with static IPs. It’s a lot of overkill that won’t make any difference in SQ and is more likely to result in configuration errors. (Also, if the D2 needs Internet access to pull down firmware updates, this will be completely broken if you go the dual networks route.)
Just connect the NUC to the router via Ethernet, just like you currently have the D2 connected to it.
In this case, there’s little difference, so stick to your PC/MAC.
There’s some improvement you can do between the router to the Lumin D2. You can isolate the noisy router by using ethernet isolator or invest on a low noise linear power for your router.
Sorry, I don’t understand the engineering behind this statement. The value of having fewer threads is that the Roon processes get a bigger time slice. I don’t think it has anything to do with electrical noise.
I don’t think any claim has been made for improved SQ due to ROCk. At least, there is no claim for improved SQ with a Nucleus/ROCK combination.
The skinny from the @danny -
https://community.roonlabs.com/t/roon-nucleus-experience/43776/33?u=slim_fishguttz
Thanks, I give the linear power supply a try!
Having few threads means the resources for the CPU is always kept low; this results in lower clock speed, thus less current is drawn. Keeping the current low resulted in overall low electrical noise. These noise can be easily seen as ‘spike’ under high CPU clock speed. A typical PC/MAC has several hundred to thousand of threads running on the background.
Since the source of electrical noise such as ground bounce can travels to DAC, this noise can adversely affect DAC performance.
Clock speed is dependent on work being done, i.e. calculations, irregardless of the number of threads/processes present. How do you feel about upsampling?
Really noisy when SSD or M.2 is accessed or video signal is generated.
Most of which are not active at any one time, A cursory look at Task Manager would confirm that.
Not for any well engineered DAC manufactured in the last 10 years.
Again, the Roon folks have never claimed improved SQ for either ROCK (reduced process count or not) or Nucleus. In fact ,they go out of their way to address that false notion.
Yes, I do, I hear an improvement in SQ, mostly in the highs; better separation of instruments and clarity. That’s why I switched from PC to ROCK. I also have a dedicated Auralic Aries Mini used as streaming transport and Roon endpoint.
Here’s is a good example why people decide to go from PC to dedicate streamers…
Please don’t.
If you want to move from MacBook WiFi to a dedicated Roon Core on LAN, simply connect it to your router/switch.
For hardware to run ROCK, consider something like this:
As for sound quality, I’ve read a report of improved SQ by switching Roon Core from MacBook WiFi to a wired setup using different hardware, for another brand of expensive DAC connected via network.
This is a little bit different but MAY be related.
Here is a well respected DAC designer (Rob Watts of Chord) talking about how using an ASIO driver may sound different to equally bit perfect WASAPI driver… both capapble of bit perfect playback obviously.
https://www.head-fi.org/threads/chord-electronics-dave.766517/page-415#post-13098194
As danny said in another thread recently, let’s not waste any time talking about bits being affected. If something is affecting bit perfect playback in your chain, you will most definitely know by audible dropouts, pops, ticks etc etc.
I don’t know if danny has discussed this with the qualified engineers at Meridian before and if they had thoughts but I wonder if it relates to similar reasons for some people (me too) observing Roon Server running on a Mac/Windows PC sounding different with RoonOS with some DACs…
Not so much just low overall CPU loading, but perhaps reducing processes that aren’t required for audio playback. Don’t ask me how it affects the analogue output or for measurements - this is just a fun discussion about potential technical mechanisms.
A qualified and respected DAC designer like Rob has the unique position of understanding both the digital side and what can potentially affect the analogue performance side…
It might be beyond the ‘bits are bits’ software/networking guys too - but maybe @danny has discussed it with the qualified hardware guys at Meridian?
This is even just looking at the example of ASIO vs WASAPI (in exclusive mode) potentially sounding different on the same hardware and same OS and same system of hardware… let alone different hardware and different OS… even while everything is playing bit-perfectly up to the DAC input…
Interestingly, 3 days ago I witnessed a dealer manually setting process affinity of the Roon processes in his US$16000 Roon Core from a Roon partner (truly impressive PC hardware by the way), in order to achieve the best SQ for his demo (of another DAC more expensive than any of our products) to a customer.
Despite it is bit perfect, the two main problems about digital audio are noise and latency. The first is obviously a big impact on SQ, most DACs are extremely sensitive to incoming noise from the source. Some goes to an extent to use galvanic isolation on its inputs.
High latency contributes to increased jitter, therefore having fewer ‘layers’ or ‘stages’ do helps to reduce this effects.
Did you think it made a difference Peter ?
Latency will have zero impact on jitter in a pure digital transport.
Using networking protocols with render-side-clocking means jitter is a non-existent thing relegated to the past.
Agreed. In the Rob Watts post I shared above, I can bet the house that he’s definitely not talking (or even thinking) about jitter there.
He explicitly mentioned RF interference potentially being a factor for why ASIO sounded different to WASAPI to his ears.
That’s a public post that I can share but I’ve had private discussions with a few others of the world’s most respected DAC designers (kept private out of respect of course) and the gist is the same.
Yes it does, take for instance a WASAPI vs ASIO vs Kernel streaming protocols all have different impact on sound quality. One can adjust from the lowest latency of 64 all the way up to 4096 or even more, in the case JRiver offers up to insane 8192. The higher latency (more buffering) means the clock generates is ‘longer’ and stay in the buffer for longer time. The longer it stays the higher the jitter.
Therefore there’s a balance between how much latency vs buffering to prevent drop-outs. Of course, re-clocking using asynchronous technique (at the DAC side) will essentially eliminate jitter. As I say, on the system level, jitter is still present but this can be taken care at the DAC side.
Yes, I agree such network protocol like LAN connection is asynchronous transmission so jitter is non existent but what about PC is connected to a DAC via USB? My argument is still jitter produced by the transport, but of course the DAC can take care of this by ‘re-clocking’ internally.
Both are bit perfect but they have different latencies which contributes to the different SQ.