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.
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.
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.
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.
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…
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.
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.
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.