So you have your electrically noisy Roon Nucleus attached directly to your DAC via electrically noisy USB with your “10% ears” and you are concerned about changes made in the Roon Core software and the changes it may have made in sound quality???
Ever time a new Roon is released, someone somewhere opines that the SQ has been adversely effected.
Don’t understand what you mean by this. Are you saying that any new feature added to Roon should be considered bloatware and that is what’s effected the SQ?
Pretty sure you’re trying to sell that mistaken belief in the wrong place.
Thanks for your engineering response. Enjoy the music
Another thoughtful and welcome idea. The answer from Emile on the relevant WBF thread is that in fact it is not a Roon issue but a server firmware change that he installed so his unit would sound better with the latest 537 build. Of course, that leaves many unanswered questions. For example, what about this units that are using the previous build? Is the SQ improved on those units as well?
Just one or two final points. I love Roon. It has changed the way I listen to music. It is sad to post a question to a lot of Roon advocates that are met with answers more akin to “the earth is definitely flat”, while assuming every new build must be better in SQ than the last. The purpose of forums such as these and many others is to query, stimulate, inform and teach. The purpose of the OP was to seek informed advice for the purpose of possibly advancing our hobby in the hope that Roons developers might gain something useful from the discourse as Antoine suggested. But when answers are received that mostly ones that are foolhardy at best, my instincts are that they do not merit a reply.
That isn’t the assumption. The truth is that for most releases, including this release, there is nothing in Roon that would change (positively or negatively) the SQ.
Taiko web site about the SGM Extreme -
-Dual Intel Xeon Scalable 10 core – 20 thread CPU’s for 20 cores – 40 threads in total
-Twelve 4Gb custom order industrial memory modules for 48Gb in total
-Standard storage provisons include 280Gb of PCIe Intel Optane storage for the operating system, 2TB of PCIe storage for music files. Music storage can be increased in 2TB increments up to a maximum of 24TB
-External connections consist of 5 USB ports, 2 copper Rj45 ethernet ports, 1 fiber SFP open slot ethernet port, 1 VGA port. SPDIF, AES/EBU single, dual or quad wire optionally available.
-No compromise linear powersupply, 400VA transformer, Lundahl chokes, 700.000uF of Mundorf and Duelund capacitors
-CNC machined hybrid copper / aluminium / “panzerholz” chassis. Completely passive cooled for fanless operation
-Custom Windows 10 Enterprise LTSC 2019 OS, Roon and Jplay playback software"
I don’t know what your background is, but this is complete and unnecessary overkill to run Roon, even using HQPlayer. It’s absurd really. Taiko is just running a number on the unwashed.
On the subject of dual Xeons, 10 core- 20 threads notwithstanding, this is from Roon’s CTO -
For best sound quality Roon recommends Core and Output on separate devices. This can be done using a Roon Ready device or a network player running Roon Bridge.
Sound quality issues where Core and Output are on the same device are usually peculiar to that device and may not occur on other devices or network configurations.
It’s not impossible that changes in the software may affect processing in a combined Core/Output device that have audible consequences. Roon makes no promises about that and doesn’t pretend to have the resources to test every hardware configuration before making software changes.
If your system is sufficiently resolving that such processing changes can alter your enjoyment of the music, then moving to a hardware configuration where Core and Output are separated is the best course.
@Speed_Racer i’ve never beaten direct connect via usb with any network solution (including innuos zenith ii as an endpoint). Though the usb direct i’m talking about has an isoregen in the chain. But yeah the network route is smoke and mirrors for a lot of people. So no need to dismiss @MGXmusicUK offhand due to this setup.
I have ALWAYS beaten direct connect (Roon Core to DAC) using the Roon Core to Roon Endpoint over Ethernet model. I used to own an ISORegen and it didn’t help enough.
See the post above yours. Roon even recommends the Roon Core to Roon Endpoint over Ethernet model for best sound quality.
I know they do. That’s the annoying thing. DAS vs NAS for library too. DAS ftw here. What’s your network setup? I’m always op to improvements.
Definitely noticing a change in sound. My wife describes it as “flat”. I would describe it as a loss of transient impact, particularly in the upper frequencies. However you describe it, the change was not for the better with this build. Using KEF LS50 Wireless with a new Intel NUC running Roon Core.
I have a wired GigE network.The sonicTransporter i9 is in my office and has an internal spinner with the music files. I am not using a NAS. The ultraRendu and DAC are in my listening room. There are no SMPSs in the listening room. Only linear power supplies. The switch I use has the negative side of the DC power plug grounded which reduces the electrical noise over the Ethernet connections.
Also, my PS Audio DAC sounds best when feeding it over I2S so I have a Matrix SPDIF 2 DDC converting the USB output of the ultraRendu to I2S.
Thanks. A lot there. How do you ground the negative side of the DC power plug?
Side question do you think the SPDIF 2 assists in reclocking in addition to giving the PS DAC the type of signal it prefers? i.e. is it an isoregen replacement?
Simple. I grounded it to an AC ground.
The Matrix reclocks the signal when converting from one digital format to another. But no, I don’t think that is a benefit. The benefit of the ISORegen is not in the reclocking of the USB signal. It is the removal of electrical noise.
I do hear some different between the previous and current versions and I believe some tweaking on the software buffering may be the cause. The software (transport) and the DAC link is governed by buffering. I noticed when you have a high buffering in the software side, more than the DAC needs to fill-in their asynchronous memory, there’s a slight difference in SQ. In other world, there’s a sufficient amount of latency to create the appreciated different. This applied to directly connected DACs such as USB-DACs.
I was able to create that difference when I’m using JRiver and USB Audio Pro with their built-in adjustable buffering system. Typically 100ms to 200ms gives the best SQ. Anything higher, the SQ will slowly degrade, especially the highs, it lacks some of the ‘sparkles’. The higher the buffering, the better the stability at the expense of latency. It is known that high amount of latency have an degradation effect on SQ.
I’m not sure how much Roon internal buffer has when it connected to a USB DAC. May be Roon guys can tell us😉
I have not noticed any change is the Roon sound signature. My system Meridian and Bluesound is Wired Cat 5e nothing fancy. Still sounds great…
If you are using endpoint, the DAC is tightly coupled to endpoint not Roon Core. The endpoint to DAC will determine the latency and buffering parameters whether it is internal or externally connected
How does buffering effect sound quality?
537 is a semi prime number - the product of two other prime numbers, in this case 179 and 3. This may well have unknown but wide ranging effects on the sound quality. Imo.
Are there any real measurements here, or just anecdotal “it sounds worse/better”? Every time we release, many people wake up with those types of comments.
Long ago (2015, when we first released DSD support), Jürgen Reis picked apart our DSD implementation with real measurements. We were able to take that and fix the issues brought to our attention. We’re looking for concrete evidence of errors introduced, or even changes between versions.
We are open to the idea that we may be missing something that’s already been stated, but when these claims are being made by a manufacturer with a financial interest, we have to be skeptical unless evidence is produced (like it has been by others in the past).
Emile has commented that his company has fixed this quality degradation introduced in 537. Great! Tell us exactly what was done to fix it and we can do the same for everyone! We’re not dummies nor are we slouches. Talk to us like professionals and tell us what you did in concrete terms.
Give us something to act on…
Why don’t YOU contact Emile and ask him to help?
As an Extreme server using I can attest that his changes resulted into marked improvement in sonics.
And no, I do not know the specifics to the changes he made. Only the man himself knows…