It just needs to be able to receive PCM samples over the network, which is a very light load, as the RAAT page explains and Danny just said. The DAC in the endpoint is more important
1 Like
Let me qualify my remark, for the money, the LINN is nowhere near the top of itâs class, in fact, many dacs for a lot less money sound better.
1 Like
Happy 420 to you!!! Cheers! Rocco, Where do you live? I live in the East Bay âŚBrentwoodâŚ
there are 4 types of things that âSQâ could be referring to:
-
problems in the digital audio signal that prevents the waveform from being continuous. With Roon, an adequately performing Core and network/USB-cable should resolve this. You can check for performance by checking the signal path and see if you have a processing line (no line means no problems), or if you do see a line, see that it is greater than 1.0x â preferably give yourself some wiggle room⌠2x or 3x at a minimum.
-
some form of digital audio signal degradation. This only occurs if someone is degrading the signal either through misconfiguration or they are trying to do something like downsampling or use a poor quality filter/volume/etc. Roon does a lot to prevent this type of error. You can always check signal path to make sure you arent having something done badly here.
-
problems in the delivery of digital data. digital data is pure information, and to move it around in space (from physical place to place), you need to map that information to something physical (even if it is just electrons). When you want to go from electrons (or whatever) back to âinformationâ, you need to make sure there is no error in reading that data. In computing technologies (TCP/IP, USB, etcâŚ), we use retransmission and âparity bitsâ and other error correction codes to resolve this. SPDIF and I2S do not, and are subject to errors here. If youâve heard the term âjitterâ, that falls here.
-
some form of analog signal degradation, otherwise known as a âsound fidelity changeâ. This would be handled in the analog part of the audio path, far away from Roon. The analog part starts with the output stages of the DAC chip and continues all the way to the brain, and is affected by the following things (amongst others):
a) the DAC chip itself, its manufacturing quality, itâs error-free operation, and how good the tech is inside in doing the conversion from digital to analog.
b) the effectiveness of moving the analog signal from one point to another without manipulating it is usually affected by cable issues, shielding from electrical noise in both the cable and the chassis, and anything else that could electrically affect the analog signal.
c) the air quality⌠is the air moving around (wind, other sounds) or is there stuff in the air that affects its vibration (rain, ballons, other obstructions)? is the room causing echos and delays? are those echos and delays causing time domain errors, gain errors at certain frequency, or causing the sound to get to you in some other unintended manner (like speaker positioning).
d) your ears and skull
e) your brain (have you been drinking, are you in a good mood?)
When people talk about âbits are bitsâ, they are saying that 2 competent systems should be able to do #1 and #2 the same, and neither can do better than the other if both are perfect. We at Roon strongly agree because we have the knowledge of basic information theory.
The problem comes in the analog stage, where things are more error prone and harder to check. It gets complicated because many believe that the non-analog stages of the signal path can negatively affect the analog parts (I can remember in-person meetings from long ago, where my Blackberry was next to the intercom, and before it beeped, the speaker from the intercom would buzz buzz).
To answer your question:
They all are critical, but the steps that have the biggest impact are in the digital domain. A break in the waveform (glitch or pop) or some digital degradation (mp3, asynchronous downsampling) can be pretty foul. But given that these problems can be easily detected, most problems with Roon are far less dramatic and live in the analog stages.
If someone would like to point out types of SQ issues that require their own new categorization, Iâm open to editing this post.
9 Likes
So much can happen here. Have you heard this music before when you were sad? Happy? Did you hear it live? How was that? Who were you with when you heard it? What were you listening to previously? Was it similar? Radically different? And on and on and onâŚ
Not really problems with Roon at that point, are they?
Sound is bits AND timing. Jitter matters. Not saying that this is the source of the OPâs issues, but I am saying youâre simplifying the problem too much.
Noone complaining of sound quality is asking about âwhy does my music stopâ?
OMG, I will never down with room like your. Smoke all day long.
I donât know what jitter youâre referring to, but thereâs nothing any playback software or networking hardware or async network protocol/interface can do about the only jitter that matters in audio: the A/D stage sample clockâs jitter.
Marketing pitch. The only âtimingâ in audio is the order of samples. The next sample to be converted is either present in the A/D buffer or itâs not.
4 Likes
I purposely left out jitter, but maybe I was wrong about that.
A stream of PCM audio data that is designated as 44100 16-bit samples and 2 channels of audio has no timing information. Each 4 bytes represents 1/44100 of a second of audio. Jitter is only a thing when you try to convert the data into analog domain and keep it âdigitalâ.
For example, if SPDIF or I2S is somewhere in the path before the DAC (and it will be), itâll be converting the digital signal into an analog waveform encoding of that digital data (but not of the analog sound signal) â thatâs what SPDIF is: an analog signal that holds digital data. Timing of the reading of that analog back into digital can be an issue if you have no way to do error correction.
Iâll add something about SPDIF/I2S in my post. Thanks!
2 Likes
You arenât, but many really do just mean âmy music skips or popsâ
I mean it as a general statement âsame bits same soundâ is wrong.
And thatâs what I mean obviously. Timing can either be internal or driven externally by a SPDIF signal.
Fair enoughâŚ
Only reason I pointed it out, possibly in an overly annoying way, is that you are a trusted voice and the claim âbits is bitsâ ignores many important aspects of the resulting sound quality. And I know you know that but the forums are likely to say âDanny said bits is bitsâ
In case of S/PDIF, the signal should have the same quality every time, provided the send buffers never overflow or underflow, regardless of the timing in the digital domain before the S/PDIF link.
Well thatâs the point: Buffering and reclocking is not part of the standard and not done in many cases precisely because of the risk of over/underrun. There are proper ways around that even in the SPDIF design: global clocks (like dCS implements) or I2S with âclockbackâ (1) (where the clock comes back from the DAC - there are such implementations). Or use a different protocol such as USB Audio or RAAT.
(1) I just made up that term! 
included jitter as point 3
1 Like
Letâs not massage together these types of protocols: RAAT and the streamer-DAC link. Roon ends at RAAT, and RAAT is a TCP-based network protocol with built-in flow control. Network clocks are irrelevant, since network speed is quite sufficient for making sure streamer buffers are in good shape at any time. From that point on, everything is equal.
2 Likes
Which are still subject to I2S usually.
You have to get the data to the DAC chip somehow. That ESS chip doesnât speak USB or TCP, and probably lacks sufficient error correction coding â but Iâve never integrated these chips into a product.
1 Like
THIS.
I speak to this ânetwork speed is quite sufficientâ here:
2 Likes