ESS (The DX3 Pro + uses ES9038Q2M) has a particular way to deal with jitter, it's unclear but they use an "ASRC" (Asynchronous sample rate converter) and what they call a "Patented Time domain Jitter Eliminator". They are indeed some of the best J-Test Graph I've seen on a Coax In. to the point I was confused at first. I guess we'd have to read the patent.
-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
Does Quality of Coax Input Matter for DACs?
- Thread starter amirm
- Start date
I presume that's another snake oil bottle closed?
DPLL = Digital phase locked loop so I guess the patent will be around precisely how the PLL is controlled.
martijn86
Active Member
Never has a power filter been as effective as this $86 digital bridge. I love that these types of scenarios are being tested by Amir. Accurate measurements with clear explanations. Thanks!
Hi, I have the FA503, and have never seen measurements of the DSP/Dac portion of it ( being equal to yours and others on the line up) do you have any or can point me to some? Thank you.
A bit off topic perhaps, but there have been some cases with DACs tested here that have had difficulty handling the incoming SPDIF signal from CD players. It has been argued that this is because the incoming SPIF signal has too high a jitter. Regardless of how it is with this, I have found that other DACs have been able to handle the incoming SPDIF signal without problems, while at least one tested DAC has not managed this. Is it possible to measure how well or poorly a DAC works in this regard?
mariano3113
Member
Honestly, from the title in my news feed: I assumed this was going to be related to Coax Cable ohm-matching and shielding quality.
Instead it was literally the COAX input and to me it ended with a familiar ring of: depending on implementation.
Instead it was literally the COAX input and to me it ended with a familiar ring of: depending on implementation.
I don't think it's off Topic. My view on this is that most these relocking algorithms or whatever we'd like to call them, rely on one thing, the incoming sample can be resynchronised to the correct clock beat only if it's not so much off the clock beat that you can't know which one it is suppose to be. At least for synchronous transfer which SPDIF normally is but in the Case of ESS they talk about Asynchronous resampling so it may be totally different, but in all cases, In DACS, this process should be fluid and if it can't reclock it IMO should have the ressource to simply revert to the incoming SPDIF clock, even if it's very Jittery. Unperfect timing is better than interruption and yes Dac manufacturers may say it's because of the poor source, but they should have thought of that situation. Not sure how to properly test that on current products tough, but it's doable in a proper implementation inside a development environment.
jannek
Active Member
No, sorry. I just had a look in the manual and found out that the DSP uses a SRC4382. The TI datasheet lists jitter attenuation under the features. For judging the DSP/DAC part only it would be necessary to grab the signal between DSP and amp - no idea if someone has done this yet.
Yes, always. Handling jitter at the receiver is the bare minimum we have done to attenuate it since the very early 90s.
In the 80s it was recover the clock from S/PDIF. Then it became recover the clock from S/PDIF and use a PLL to lock a new clock source onto it. Then it became filter the incoming S/PDIF signal, sync only on the pre-ambles which are the most stable transitions in any S/PDIF frame in the time domain and use a PLL to lock a new clock source onto it. Then we did dual stage PLL, using one for clock recovery and a second for more stable reclocking.
When we talk about sample rate conversion jitter is reduced even further by necessity. This is because any data timing errors at the input to the sample rate converter are distributed across the new sample rate as a ratio of the input vs output sample rate, and that mathematically could cause very minor jitter to be massively multiplied. So to compensate this SRCs massively oversample the input, and filters it before resampling and then decimating to get the output. So while there is a lot of people who say ASRC doesn't reduce jitter they are correct about only part of the process.
mash
Active Member
- Joined
- Oct 8, 2020
- Messages
- 130
- Likes
- 274
One of the questions that I've always had is if there is much/any differance between using a S/PDIF -vs- a COAX connector in these types of scenarios (in this case, running out of the DAC-SQ3). I would assume no, that any decent DAC would negate any differance between the two digital transports but wanted to ask the question anyways.
I remember watching a movie of the first music studios using pro tools.
It took hours to do simple edits! Now digital and computing power has come a long way, It's nice to know that once digital even cheaper units maintain quality.
It took hours to do simple edits! Now digital and computing power has come a long way, It's nice to know that once digital even cheaper units maintain quality.
Thank you for providing such great and rare tech-talk. Unfortunately I got stuck on this statement that I don't know what to make of...
@amirm statement maybe a partial answer to @mariano3113...but I can't be certain.
Last edited:
Amirm fully answered this. Yes it is dependent on implementation. But every Dac made in the last 15-20? Years implements clock regeneration - which is supposed to eliminate jitter at the receiver.
There are a few that don't do a good job of this, but it is easily measurable and you won't find any in the top half of the bar chart of tested dacs.
RF theory, impedance matching (VSWR, etc) are the bedrocks of RF transmission; I got that and thank you!
But your reply complicates matters unnecessarily bcuz jitter created within any DAC processing and degradation due to tranmission thereof are related but different topics when it comes to jitter causes from active circuitry (re:cables/coax)...
KSTR
Major Contributor
The Audio Precision Analyzer allows to dial in various amounts and types of jitter on its digital outputs (AES3, SPDIF, TOSLINK) so one can test at which jitter levels (pathological cases, mind you) any modern DAC starts to loose sync. And before it does, one can measure degradation with the J-Test signal. As far as I can see, Amir uses the J-Test mostly over USB where it is almost useless (and thus seldom shows serious degradation). J-Test was designed to be used with standard DAI connections (AES3, SPDIF, TOSLINK) where the clock is recovered from the signal.
I seriously doubt the problem some DACs may have with some CD transports/players is any related to jitter. CD transports/players are not jitterbombs and DACs should easily handle this in any case.
And to create relevant levels of jitter in the cable itself there must be a significant line termination impedance mismatch at the sender and the receiver, plus the cable must just the right length that the reflections (first back from receiver, then forward from the sender again) line up with the edges in the waveform. Another source of jitter (of a different type) would be truly horrible dispersion characteristics of the cable, with time-of-flight vs frequency being very irregular, not constant, which could severely round off the edges.
I bought a Topping D30pro and it is unable to connect to my Cambridge CD player. My RME ADI-2 DAC connects to the same CD player with no problem. The explanation I got from Topping is that this is due to huge jitter from the CD player. I have learnt from others that this is a problem for more owners than me, and with several different brands of CD players, and not just a problem with this specific model from Topping.
KSTR
Major Contributor
Understood. This could only be asserted by testing it for jitter problems with the AP with the SPDIF connection (or was that with TOSLINK?). In my limited testing with my own AP I always had to dial in truly massive jitter and/or very low signal levels to provoke connection and syncing problems. If the Toppings behaved severely different than many other DACs, say, the RME, it would show up quickly.
- Joined
- Oct 29, 2018
- Messages
- 35
- Likes
- 60
Hmm, it sounds like a lot of additional work is required to recover a signal from coax/toslink as opposed to USB (or maybe I'm misunderstanding). What effect would using one digital transport over another have on delay going from PC > DAC > Amp > Headphones (for example)? Similarly, how much delay is actually added to this same chain by adding a device like this to first convert USB to coax/toslink before going into the original DAC?
Similar threads
