I actually did try the 10/100 vs gigabit and there was no difference.
Yes I did try to remove roon and install a new.
Well I can only pray for lumin somewhere in the future will integrate Roon in their products…
I understand that you guys an myself has tried a hole lot of things and nothing works…
but it’s really really REALLY bothering me that many of you says roon sounds better, cause I my town There are three of my buddies who also Can’t get roon to sound good.
They all say that they suspects the “heavy” software(roon) to be the issue, and they also (like my Hifi pusher) think that it’s because roon is not installed directly in the streamer/dac (i this case Lumin A1).
If this is the case then maybe roon on the nucleus or an Innuos server may be the way to go for someone starting from scratch, but don’t know where that leaves you with all the equipment in place
It’s just a NUC i3 inside the Merging+PLAYER and is essentially running ROCK. So there’s nothing extra special about the Core side of the Merging+PLAYER. As a DAC obviously it’s pretty special but that’s a separate thing.
And having Roon Core inside the same box/housing as a networked DAC, is the complete opposite of Roon’s own general recommendations, which is why I mentioned to test with your NAS far away from your listening room (I know you confirmed you tried it). Roon recommend your Core be outside the entire listening room… let alone having Core inside the networked DAC.
as stated previously, Roon doesn’t have attributable SQ unless you’re using its DSP capabilities (including volume levelling). Outside of that, getting a great sounding system utilising the Roon ecosystem is pretty trivial (but perhaps not to folk who believe that the length of an average run Ethernet cable can influence what they’re hearing).
Run Roon Server on a PC that meets Roon’s minimum requirements (they’re specified to ensure you have a good Roon experience)
If your DAC is Roon Ready, connect Roon Server and DAC to switch
If not and you’re forced to use USB don’t connect the server directly to your DAC via USB, use a lightweight intermediary running Roon Bridge which in turn connects to your DAC. If you want to power the intermediary via LPSU, by all means…depending on the intermediary and the quality of your LPSU incl. its ability to reject incoming noise it may well reduce electrical noise bleeding into the DAC, resulting in a lowered noise floor. Clearly audible on cans and high efficiency speakers.
unless your Roon Server is silent, locate it outside your listening environment
Beyond these basics the rest is trivial pursuit for those so inclined.
Seriously, Roon doesn’t have a sound : it just transports data to endpoint/s - your data & your endpoint/s.
It’s not helpful or correct to say that it’s Roon that sounds bad and it distracts from the problem you’re trying to fix.
It’s your equipment / environment that’s the problem, not Roon.
If the lan cables make a differance then that’s nothing to do with Roon. The audio leaves a Roon bit perfect and if you have dodgy cables you degrade that.
If you believe in the cable makes a differance then better cables are only optimising Roon. I think of it this way, ‘Expensive cables may not give you a sound advantage but perhaps they assure you that you are not at a disadvantage’.
In the finish, sound quality will come from your audio system. And maybe the cables in between.
it was general belief few years back that bitferfect is always the same.
however as time progressed people learnt that timing is crucial (jitter)
…also EMI/RFI play it’s role in high end audio
…ground noise leakages anyone?
not to mention SMPSes polluting power lines and therefore ideally not to be present on same circuit as audio chain
to my belief there is still room for improvement regarding RAAT client related to how even is the client cpu loaded, possibly improvement on buffering etc
@Thomas_Larsen
If your last comment was directed at me, then you’ve just proved my point.
You’re suggesting that changing LAN cables has an effect on Audio - well - that’s your ‘experience’ - in your environment - on your system.
That means it’s a very specific combination of variables & circumstances - but they’re your variables & your circumstances.
So you changed the LAN cables - and what did Roon do?Nothing. Nothing different at all.
It didn’t react or do anything any differently. Why would it? It sent the same data signal & the same data signal arrived, otherwise you would hear noise.
If I type “ethernet protocols are error-resistant” into my PC using a certain set of LAN cables in my network & then substitute another totally different set / combination of LAN cables and type it again, do you see - on this website (which means that the data signal that I’ve submitted has passed through thousands, or tens of thousands, or millions / billions of cables & switches etc. which could also have had an effect) - do you see “sdfsefsdfsdfsdfds” or do you now see & read “ethernet protocols are error-resistant”?
If you change a variable in your system & there is a reaction, it’s quite clear that your system is sensitive to change - and that the variable in question holds the key - but don’t “shoot the messenger”…the message sent was identical…
Just trying to help : to get focus on the problem…
Your audio endpoint should take care of all that if it’s properly designed. In my case, I use a Meridian MS200 that buffers the audio, and apodizes/upsamples. Jitter etc is well understood.
Sounds great here.
To my mind there’s plenty room for improvement if people sweep the audiophool cobwebs out of their belief systems. To assume that you know RAAT can do better when you know nothing about how it operates and how it was arrived at, having been developed specifically to address shortcomings in dealing with audio streaming is quite something. Please forward your CV to Roon so we can all benefit from your expertise.
@evand let’s stay constructive without invectives please.
by coincidence i know few things about RAAT based on my observations and information published by Roonlabs. It’s obviously not enough to propose specific changes for improvement, however we know there is always a room for improvement and as i know my system and can do direct comparison between different streaming SW and endpoints i know what i hear.
I would be most happy having the same SQ from Roon (or even better if possible) as i am getting from UPnP/OpenHome because the interface and features are fabulous. Therefore i want to be constructive and i am asking others for being open minded instead of being dogmatic - at the end it should be benefit for all (except Roonlabs competitors )
There’s a difference between being open minded and making sweeping statements such as that you made. What your ears tell you is subjective experience, are you open-minded enough to consider that for a second?
That’s why I ask my wife to do the listening when I’m comparing different components/system configurations. She does not know or care what hardware or software is involved, but she has a very good ear for music and she gives consistent, specific comparisons when there is a discernible difference.
I’ve been in the R&D side of computing for decades, and over that time I’ve encountered occasional differences in performance or accuracy between algorithms/systems that were very, very hard to explain let alone fix. One thing to keep in mind is that all sufficiently complex hardware/software systems have bugs, and that testing is simply unable to reach all the possible combinations of software and hardware versions. Since I got into lossless digital audio, I’ve read several discussions like this one where people disagree on whether software or hardware components X and Y behave the same or different. The problem is that X and Y are never isolated, but X is operating in the context of X1, …, Xm while Y is operating in the context of Y1, …, Ym. For all we know, the real difference is between Xj and Yk, not between X and Y. In particular, knowing what I know about the challenges of designing and testing realtime software, I’m not at all convinced that the delicate handover between networked data transmission and synchronous digital DAC input is done equally well in all the different hardware/software combos that are typically invoked in discussions of this kind.
Just to speculate a bit, a priority inversion bug in the system software stack that supports that handover could be enough to inject timing glitches in the synchronous stream into the DAC. Roon could be blameless, but it might tickle such a bug more than the totally different UPnP/DLNA stack. Be really glad that we are discussing audio, not automotive safety or the failure of a very expensive space mission…
Sure there are sensitive issues in the audio part of the chain.
But some statements in this thread do not hold up.
For example, jitter is not an issue in RAAT.
Wikipedia: jitter is the deviation from true periodicity of a presumably periodic signal. But the network is asynchronous, even out-of-order. So by definition, it cannot exhibit jitter.
)
) lesson I had to learn a couple of months ago.