Version 1.8 improved sound quality

We all agree a computer can generate noise. But isolating the DAC from the computer, noise handling is simple. It’s actually a part of Roon’s architecture and selling points.

2 Likes

Huh? What does this random string of words mean?

We’re still talking about the protocols used to get the data from the core/server to the bridge/endpoint, right?

What ground plane where? How does it factor into the network protocol? This noise you seem to obsess about is not the sound kind of noise. You do realise that I hope.

Rob Watts, the Chord designer, has said on multiple occasions that dealing with RF is like dealing with a fungus. It’s really hard to eliminate.

If RAAT is very chatty - then it will cause activity in the endpoint’s CPU. Yesterday I posted a blurb from their release notes for 1.3 where they said they “found that using TCP reduces CPU load on the audio device and in the core–primarily by reducing the context switching overhead associated with “waking up” for each packet.” So clearly communicate with the endpoint can cause activity within the endpoint. So what if they are over-communicating with the endpoint? I’m not saying they are but it stands to reason that if they are, doing so could potentially degrade audio performance.

I may be wrong but I took it as a list of reasons why someone with a different view would blame someone else for not agreeing. For example, you can’t hear the same as me because your ears aren’t good enough or your Hi-Fi isn’t transparent enough.
I can’t follow most of the techno waffle on here so apologies if that wasn’t written with some irony in it and I misunderstood.

You need to consider the layers beneath the protocol as well - particularly the physical layer. The protocol isn’t the only factor in determining sound quality. The protocol might be the least problematic part of this.

I’m sorry but I have to ask. Do you connect your devices together at home using any copper wire? So then why are you only “talking about the protocols” here?

Are we still talking about improving the sound quality of v1.8 or SQ more generally? If it’s the former then I can’t see how the physical layer has any bearing on the discussion.

The OP hoped that the next version would improve sound quality. The physical layer is more about general sound quality.

If this isn’t the case, then how can different end points or wifi vs Ethernet sound different? I’m seriously asking what the cause would be?

I hear differences, however minor and I’m using top end equipment, Chord mscaler/Dave.

I also want to point out my results go against my expectations, which is I expected no differences. And then RAAT vs Sqeezelite, if no difference I thought I like Squeezelite more just based off article posted. Same for Ethernet to sound best. Came to opposite opinions after testing.

Yes, maybe we can now make a hypothesis than can be tested. I give it a shot: Is Roon/RAAT’s endpoints software so “heavy” that it introduce audible RF noise a in given streamer + DAC?

If true, It will of course be valid only for specific (types of) products/implementations (noise free use of Roon exist, so we can rule out that it’s a general problem). I would guess streamers with a integrated DAC would see this problem more often (a streamer connected to a DAC with TOSLINK will never).

It’s plausible. Personally I don’t think it is a real world problem, but that does not matter - I try to keep my opinions out of discussions like this.

I can’t wait 'till 1.8 comes out and breaks a lot of stuff so there will be something else to talk about instead of this and audiophile switches.

2 Likes

Thank you for your kind response. You are absolutely correct that this isn’t a “real world” problem. Many other problems can easily mask this. The starting point, unfortunately, are those systems that have been optimized for low noise.

I wouldn’t say my views on this topic are simplistic - I think there are quite a few negative connotations we can attach to that particular word - I would say that a lot of the discussion is beyond my level of understanding. However, as I understand it TCP is a standard form of communication that doesn’t have a loquacious mode, or any other sort of mode that would determine under or over-communication - it is what it is. Also, as it’s been around for many years now, I suspect it’s probably about as efficient as it’s going to get. In a nutshell then, I’m also struggling to see how Roon could possibly over-communicate. What would that mean in this context?

1 Like

That can of worms should not be opened here. I do think there are a couple of great forums where this is discussed freely such that one can begin to get an understanding of what’s at play here. This certainly ain’t the place for that but if you send me a PM, I’ll provide you with a few links.

It’s just you have many saying differences aren’t possible but then I hear them. So either I’m crazy or there’s a scientific reason. I believe in science and if it’s not possible, then I’m just hearing things and going crazy :stuck_out_tongue_winking_eye:

I just ask that you try avoid putting words in my mouth. I did not say that Roon was over-communicating. I said “If RAAT is very chatty”. I then pointed to the fact that they said this: "reducing the context switching overhead associated with “waking up” for each packet. You asked about over-communicating and how that would be possible with TCP. Clearly there’s a “context switching overhead” and it’s only reduced with TCP. Likewise they mentioned that “TCP reduces CPU load on the audio device”. They didn’t say it eliminates it. Activity is occurring at the endpoint - including CPU load and “waking up” for each packet. Do these things matter? Well Roon seemed to think so.

You are crazy. Me too.

I really wish it would be easy to invite people over to hear this for themselves. They can wear two masks - with one covering their eyes so they don’t know what I’m changing. If they are fair and honest they will find themselves quite astonished by the magnitude of differences.

No, what you said was " So what if they are over-communicating with the endpoint?", by which I assumed you meant Roon, as RAAT is clearly not a ‘they’ and I can’t think of anyone or anything else you might have been referring to. Again, my apologies for causing offence, but it was a genuine question, I don’t see how it would be possible to over-communicate using TCP or, if you prefer, be “very chatty”.

This is where I think I differ. I think most wouldn’t even hear the differences. I think these are so minor but you can become obsessed with these differences, they can bug you. For me I hear them when switching but quickly adjust.

This even goes for the mscaler. You see a lot of people trying to hear the differences. When they do hear, they can’t unhear it and then know it’s a keeper. I’d still be happy if I had to sell the mscaler but like it better with it.

To be worrying about roon sound quality is just nitpicking.

TCP is at level 4 - the transport layer. This layer simply provides “host-to-host communication services for applications”. Each of the seven layers need to be considered here.

Look what you did.

3 Likes