Version 1.8 improved sound quality

[Chrislayeruk (Chris)]

People who worry about noise should invest in the many expensive gadgets available to mitigate the issue.

[ToneDeaf (Ozzie)]

I want Roon 1.8, and all subsequent releases, to focus on pitch perfect reproduction of birdsong, and birdsong only. And the much undervalued sound of silent contemplation.

[iamoneagain]

Yes, I can use roon as the front end following the setup where you Enable Squeezebox support in roon’s settings. And then Stack Audio uses commercial version of Ropieee and can enable Squeezelite. Then roon sees that as a Squeezebox connection. At that point I can transfer between the roon endpoint and the Squeezebox one even though it just the same streamer.

I could happily live with the Sqeezelite endpoint setting and it sort of sounds richer but the roon end point setting feels like has more space around instruments and blacker background. Maybe if I didn’t have the mscaler,I choose Squeezelite. I might activate again just play with it a little longer.

[AE67]

Everyone afraid of noise crawling through the ethernet cable can simply use a Wifi connection. No cable, no noise and you can safe a lot of money for cleaning gadgets and Roon don’t need to waste manpower to ‘improve’ something…

[Ken_Bauernfreund (Ken B)]

The following is from the 1.3 release notes. Here they discuss RAAT’s network tuning. My reason for sharing this is to show some of the tradeoffs Roon had to consider to effectively pass a bit perfect stream. Perfection doesn’t exist in the real world. Engineering always comes down to balancing competing needs. Achieving better sound quality might come at the expense of something else that Roon isn’t willing to give up.

“We 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. Using TCP also allows us to offload work associated with re-assembling the packetized audio stream from RAAT to the operating system kernel on the audio device, where it can be implemented more efficiently and simply.”

“We also found that TCP is a lot “friendlier” to poor networks and routers. Not all router manufacturers perform extensive QA with high-resolution UDP audio streams, but they all test to make sure Netflix and Youtube (both TCP-based) work. TCP is also less likely to create trouble with exotic network setups–managed switches, jumbo frames, etc. If you have experienced trouble with these, it’s definitely worth taking another shot to see if the new protocol is easier on your network.”

[AE67]

@Ken_Bauernfreund

The following is from the 1.3 release notes. Here they discuss RAAT’s network tuning. My reason for sharing this is to show some of the tradeoffs Roon had to consider to effectively pass a bit perfect stream. Perfection doesn’t exist in the real world. Engineering always comes down to balancing competing needs. Achieving better sound quality might come at the expense of something else that Roon isn’t willing to give up.

You took the wrong conclusion. All these points Roon mentions in the post can lead to dropouts not to a degration of SQ. That is how TCP works.

[iamoneagain]

The counter argument is WiFi causing more noise. But really Ethernet is better because no chance of drop outs.

I personally think all these differences are minor and shouldn’t effect overall enjoyment. It’s more of just tweaking especially if have a very revealing system. I would think direct connection to the core sounded excellent until directly compared to streamer connection. The differences in software are even more subtle.

I tend to disbelieve most of this stuff until I hear it for myself. Comparing Squeezelite setting to roon didn’t cost me anything but time, so figured I’d check it out.

[Ken_Bauernfreund (Ken B)]

@Chrislayeruk

People who worry about noise should invest in the many expensive gadgets available to mitigate the issue.

They can make more apparent the harm Roon does.

[Andreas_Philipp1]

@Ken_Bauernfreund

My reason for sharing this is to show some of the tradeoffs Roon had to consider to effectively pass a bit perfect stream.

I fail to see the tradeoffs. In the cited paragraphs it’s all about the advantages of using TCP. No disadvantages are being introduced.

[iamoneagain]

I read that too as saying their choices were for a more efficient endpoint, which to me could be better sound quality. Didn’t sound like they made sacrifices.

[AE67]

@iamoneagain

The counter argument is WiFi causing more noise.

Please explain

[Tim_Rhodes]

Even if you weren’t before, you are just trolling now.

[Frank_Daman]

@Ken_Bauernfreund

This is one of the definitions of “noise” in the dictionary: an electric disturbance in a communications system that interferes with or prevents reception of a signal or of information.

The bits in question are information, not part of a signal - signal to be read as processed data. Pure data is either transmitted and received or it is not. There is no interference through “noise” that might alter the bits. Zero is zero and one is one. Full stop.

@Ken_Bauernfreund

exactly the right time with no noise coming along for the ride.

Timing is immaterial in network transmisslon. Data is buffered at reception and the DAC’s clock will handle the timing. As mentioned before: this so-called noise cannot alter the value of either zero or one.

@Ken_Bauernfreund

there are at least three things a music player must do: 1) pass the exact bits 2) pass them at the right time 3) minimize disturbances that could degrade audio performance.

Music player is a sloppy definition since the actual “playing” doesn’t start until the DAC starts processing the bits. How the bits get to the DAC is immaterial
This brings us to point 1): as long as the bits arrive it doesn’t matter which protocol is used.

Point 2): cf.buffer and clock

Point 3): cf.value of one and zero

Perceived differences in sound may or may not be extant. If extant, the cause will not be the transport protocol but will most likely originate in the DAC’s signal processing path, i.e. different internal routing of the signal depending on the transport protocol or some such.

Why does this pointless discussion always rear its ugly head?

[xxx (Banned - toxicity)]

@Frank_Daman

Why does this pointless discussion always rear its ugly head?

Because people engage in it.

[iamoneagain]

So I only said that because I’ve come across in articles but I personally wouldn’t go that crazy worrying about stuff like that.

Here’s an article that mentions how could be worse but take with a grain of salt.

Ethernet or WiFi - which is better for high-end audio streaming? | Darko.Audio

I think worrying about the changes software and noises make are almost for those of us with ocd. My system sounds amazing and with any of these changes, it still sounds amazing. Maybe just slightly different only if know what to listen for.

[Ken_Bauernfreund (Ken B)]

@AE67

@Ken_Bauernfreund

The following is from the 1.3 release notes. Here they discuss RAAT’s network tuning. My reason for sharing this is to show some of the tradeoffs Roon had to consider to effectively pass a bit perfect stream. Perfection doesn’t exist in the real world. Engineering always comes down to balancing competing needs. Achieving better sound quality might come at the expense of something else that Roon isn’t willing to give up.

You took the wrong conclusion. All these points Roon mentions in the post can lead to dropouts not to a degration of SQ. That is how TCP works.

No, you took the wrong conclusion from what I posted. I clearly stated my reason for sharing. I’ll repeat it. “My reason for sharing this is to show some of the tradeoffs Roon had to consider to effectively pass a bit perfect stream.”

But since you mentioned it, more dropouts means more retransmissions which could very well lead to noise that can degrade sound quality.

[Ken_Bauernfreund (Ken B)]

@Frank_Daman

@Ken_Bauernfreund

This is one of the definitions of “noise” in the dictionary: an electric disturbance in a communications system that interferes with or prevents reception of a signal or of information.

The bits in question are information, not part of a signal - signal to be read as processed data. Pure data is either transmitted and received or it is not. There is no interference through “noise” that might alter the bits. Zero is zero and one is one. Full stop.

Because we are talking about sound quality. You yourself mentioned the different stages that the signal has to go through to get us sound. Noise degrades sound quality so any discussion about sound quality has to consider more than just the bits.

And no zero isn’t zero and one isn’t one. Generally these values are determined by comparing voltages against a reference voltage. When the signal crosses the lower threshold we get a zero and when it crosses an upper threshold we get a one. Noise can impact the detection of that crossing such that timing precision suffers.

The reason this discussion keeps raising it’s head is because a good number of individuals keep holding onto simplistic representations that bear no resemblance to what’s really going on in the real world.

[Ken_Bauernfreund (Ken B)]

@AE67

Everyone afraid of noise crawling through the ethernet cable can simply use a Wifi connection. No cable, no noise and you can safe a lot of money for cleaning gadgets and Roon don’t need to waste manpower to ‘improve’ something…

RF is well known to harm analog circuits and degrade sound quality. WiFi access points are essentially RF generators. Bathing the signal in RF is probably not the best way to reduce noise.

[AE67]

@Ken_Bauernfreund

RF is well known to harm analog circuits and degrade sound quality. WiFi access points are essentially RF generators. Bathing the signal in RF is probably not the best way to reduce noise.

I hope you don’t have a fridge in your house. They are much bigger RF generators even from a higher distance. And don’t take a mobile phone inside the room you want to hear music.

[Chrislayeruk (Chris)]

For that you have to accept Roon does harm, I do not accept this