No so. Clearly nativeX is not converting sample rates so it is not ASRC. However, it works on all inputs, not just USB, and runs all inputs in asynchronous mode.
Asynchronous Sample Rate conversion (ASRC) DACs
- Thread starter jkeny
- Start date
No so. Clearly nativeX is not converting sample rates so it is not ASRC. However, it works on all inputs, not just USB, and runs all inputs in asynchronous mode.
Oh, OK, I read this on their site & interpreted incorrectly "New features of the Mark II include 192kHz 24 bit asynchronous USB, NativeX mode," I went deeper into their site & see that nativeX is in fact also called "digital Lens" which,AFAIK, in my simplistic understanding, is a large memory buffer to receive the samples & separate clocks to clock out the data.
Can I ask if there is any noticeable difference between digital inputs or digital cables when the nativeX is used? In other words why did you go for the expensive Off-ramp 4 if nativeX removes 99% of jitter anyway?
Good question. I have $6,000 worth of hardware (Caps 2.0, Offramp 5 with turboclocks + monolith PS) and $2,500 worth of cables (synergistic USB, Transparent AES/EBU) lined up to feed the asynchronous PWD MKII low jitter bits, when in theory the DAC should be 99% immune to incoming jitter.
I convinced myself I can hear a difference, but I could simply be the biggest sucker in audio (I'm in good company here). What is reassuring to me is that I hear difference between all the input modes (i.e. the bridge, the I2S out of the offramp, and the AES/EBU out of offramp).
For the record, if incoming signal would not matter to asynchronous DACs, all reputable USB dacs should be immune to transport quality, and a $300 PC would suffice as s source. Clearly, this is not the consensus among USB dac users.
So one of two possible reasons (that I can think of):
- it doesn't remove all the jitter it claims & what's left is still audible
- something else besides jitter is different between the inputs & makes them sound different - noise perhaps or ??
According to USB converter guru Steve N. @ empirical audio no asynchrous input is 100% immune to jitter.
Also, Paul McGowan was shocked to find his bridge / I2S input improved with the MKII board, which should not have happened in theory.
I conclude there is a lot of voodoo going on with these bits.
Yes, these arguments and problems are unnecessary if the system is all locked to the DAC's sample clock e.g. asynchronous USB. Otherwise, there is no sensible way to completely eliminate timing inaccuracies (whether you define that as jitter or interpolation errors).
This is an example where the expensive solution (the outboard DAC) may suffer an inherent weakness compared to the budget solution (DAC built into CD player/PC).
No system is 100% immune to jitter. The problem asynch DACs are solving is really one of keeping the data stream constant and clock clean (no cycle slipping, no dropped bits due to a glitch or delay, no big clock modulations as your PC farts around with other things), errors that effectively create jitter at the DAC. By isolating the DAC and it's data stream from the USB data stream (and power supply noise), asynchronous converters eliminate (or at lesat greatly reduce) one of the biggest error sources from USB.
Asrc
Came across some measurements by Emotiva.
They have a DAC with defeatable ASCR.
Jitter spectrum at 44.1k with ASRC disabled
Jitter spectrum at 44.1k with ASRC enabled
Source: http://emotiva.com/resources/media/xda2/xda2_asrccomparison.pdf
Came across some measurements by Emotiva.
They have a DAC with defeatable ASCR.
Jitter spectrum at 44.1k with ASRC disabled
Jitter spectrum at 44.1k with ASRC enabled
Source: http://emotiva.com/resources/media/xda2/xda2_asrccomparison.pdf
Further reductions of the already inaudible. Jitter is the harmonic distortion of the digital age.
Tim
Tim
Maybe but also maybe Amir's post applies "If the thing jumps back and forth to stay in sync, such error would not show up as jitter since output clock is fixed. Yet it will create non-linear distortion." So it turns out to be a nice way to convert jitter (which results in non-linear distortion) into another form of non-linear distortion
Perhaps. Interesting numbers though. Here we have an Emotiva DAC. Most of the high end would sniff, to say the least, at such midfi. And what is it doing in at its best? It's reducing jitter from - 110 dB to - 125 dB. I am amused.
Tim
Tim
Even more amazing is that companies even with lots of resources usually don't! Here is an example:
Everything other than the middle tall spike are distortion/jitter components.
That said, the J-test signal Emotiva used is inappropriate in this case. It is designed to show jitter. It has no effectiveness for asynchronous sample rate conversion. What I don't like about ASRC is that it is always in the loop. Even for an ultra clean signal, it is resampling. Instead I like to see people do a good job at the start and not need to use this circuit. Here is an example of that:
How about this type of jitter found by renowned Grammy award recording engineer and engineer Roger Nichols (taken from his resume)?
2000
Discovered that the CD pressing master can cause jitter in the CD playback by how it is peeled off of the glass master
(Steely Dan “Two Against Nature”). Warner Brothers modified their CD production methods.
He has an mind boggling resume including interesting consulting with John Ulrich then with Infinity, on the first digital amplifier back in 1970! BTW, he also did the first 24 bit commercial CD "Bela Fleck Live Art" in 1996.
2000
Discovered that the CD pressing master can cause jitter in the CD playback by how it is peeled off of the glass master
(Steely Dan “Two Against Nature”). Warner Brothers modified their CD production methods.
He has an mind boggling resume including interesting consulting with John Ulrich then with Infinity, on the first digital amplifier back in 1970! BTW, he also did the first 24 bit commercial CD "Bela Fleck Live Art" in 1996.
Yeah, HDMI is bad. They could really do a lot better, but seem to be more concerned with loud and deep than good in the world where HDMI is the standard. But the S/PDIF? -90 dB? Really? Under just the right circumstances I suppose you could hear it if you were listening for it, but I still think it come awfully close to falling into the category of further reductions of the already inaudible. It's something I might worry about after I had everything else perfected, but not much sooner. Fussing over this and waxing poetic over a turntable? A little perspective...
Tim
Tim
That being the case, I believe I'd just leave ASRC disabled and suffer jitter at -110 dB.
Tim
The point of the post was that you can get clean clock using good circuit design without resorting to ASRC. The ASRC as it stands has unmeasured performance since no one has created a good way of exciting what it does.
Amir what do you mean by 'exciting what it does' ? Do you mean provoking it into showing artifacts?
ISTM that the problem with ASRCs boils down to an epistemological one - how do they 'know' what the original sample rate actually was? They try to work this out from the incoming (jittered) samples only. Perhaps ASRCs would benefit from having some kind of internal model for how timing errors occur, then they could use the model to improve their estimate of the original (unknown) rate. So far I've only seen in the various semiconductor implementations simple low-pass filtering used on the incoming samples - averaging in other words. Yet averaging will perhaps result in noise (timing errors) being moved down from higher to lower frequency, just where the golden ears say that jitter becomes more critical.
ISTM that the problem with ASRCs boils down to an epistemological one - how do they 'know' what the original sample rate actually was? They try to work this out from the incoming (jittered) samples only. Perhaps ASRCs would benefit from having some kind of internal model for how timing errors occur, then they could use the model to improve their estimate of the original (unknown) rate. So far I've only seen in the various semiconductor implementations simple low-pass filtering used on the incoming samples - averaging in other words. Yet averaging will perhaps result in noise (timing errors) being moved down from higher to lower frequency, just where the golden ears say that jitter becomes more critical.
Yes exactly. Instead of just toggling the low-order bit as J-test tries to do, we need to induce rate changes and see how they track the input and what artifacts they generate at the rate changes. Tracking errors here as you explain create distortions.
ISTM we rather do need a specific jitter test signal designed for HDMI - J test was specific to AES3's use of bi-phase mark coding and designed to provoke that into doing its worst. Presumably HDMI has different foibles as the physical layer's different?
Similar threads
