"can anyone explain how quality of clocking at various point in the chain will impact final SQ, and how I can best allocate my "clocking funds"."
This depends on the mode that you use for the PWD. If you use resampling mode or NativeX mode, then it is using internal clocks, so the effect of a low-jitter input will be less, but still noticable IME. It's strickly marketing that says that all jitter is eliminated. Never happens.
I have yet to find a DAC that is not improved by a low-jitter source.
If you use Native mode, then the jitter of the source is critical. This mode feeds the D/A directly. This is where a low-jitter input can make a huge difference. Feedback from one PWD owner demonstrates that on this forum.
If the Trinnov has an external word-clock input, it means that the internal clocks are PLL controlled, which will cause higher jitter. The good news is that a reclocker can easily be inserted after the Trinnov to remove the jitter. The reclocker can drive the word-clock input on the Trinnov and synchronize it to the reclocker. This allows a free-running clock to be used in the reclocker, delivering the lowest jitter datastream.
Steve N.
Empirical Audio |
The literature on the PWD MkII indicates that its NativeX Digital Lens function "Will reduce incoming jitter levels to below 1 pico second, regardless of how jittered the incoming signals are .... NativeX works on lowering jitter on any selected input on the PWD. This means even highly jittered sources such as an Apple TV or a computer sound card will suddenly have a fog of jitter removed. The feature is rather remarkable."
With that function switched in, I would therefore expect that clock jitter at points upstream (earlier in the chain) would be irrelevant. However, the fact that NativeX can be deselected is a little disconcerting, because it suggests that it may have audible side-effects. Perhaps side-effects that are similar to those that are sometimes claimed to result from ASRC (Asynchronous Sample Rate Converter) technology, which as I understand it reduces jitter by means of a calculation that is arguably imperfect.
The results of your experience using the NativeX function in conjunction with the Bridge, assuming you have been using NativeX with the Bridge, may not be indicative of the side-effects it would have when used with an input that is more jittery, given that the Bridge has its own built-in Digital Lens function that reduces jitter.
You might want to contact PS Audio and see if they can give you a better idea of the possible downsides of NativeX, when used with a jittery source. And also what degree of jitter reduction the design provides, if any, when NativeX is deselected.
If you end up choosing not to use the NativeX function, what you would want to focus on would be minimizing jitter at the interface between the Trinnov and the PWD. I'm not familiar with the Trinnov, but perhaps using its external clock option would do that, or perhaps the jitter on its output would be sufficiently low even without that option. Or you might want to consider putting a good reclocker just ahead of the input to the PWD. In either case, I wouldn't expect jitter further upstream to have any relevance.
Regards,
-- Al |
In the analogue domain the slogan garbage in will make worse garbage out. Get the best sorce you can and let the chips fall where they may. But digital aint so. My opin is the last clock is the important one. OTOH Steves Offramp I2S seems like a bridge / PWS killer |
I will be using NativeX since this is the best sounding mode. I'm still a bit confused about the impact of jitter upstream. For example, if the input signal into the Trinnov has high jitter (say I use a poor USB converter), the DSP processes this poor quality signal. To what extent would this impact the end SQ result if most jitter is eliminated downstream, just before the DAC? |
"To what extent would this impact the end SQ result if most jitter is eliminated downstream, just before the DAC?"
Anybodys guess is as good as mine. It may have no impact. If you try different sources and cables with the Trinnov and the sound is different with any of them, then there is your answer. It can probably be improved with a low-jitter source into the Trinnov.
Steve N.
Empirical Audio |
If the input signal into the Trinnov has high jitter (say I use a poor USB converter), the DSP processes this poor quality signal. To what extent would this impact the end SQ result if most jitter is eliminated downstream, just before the DAC? Jitter is only relevant at the point where digital data is converted to an analog signal. The DSP process is entirely in the digital domain, where "bits are bits," assuming there is no outright malfunction. So jitter on the input to the processor won't matter as long as it is reduced to insignificance at the point where d/a conversion occurs. Regards, -- Al |
Thanks guys. I guess its back to trial and error. Keeps me busy and is part of the fun. |
I feel your pain. My system has 4 clocks in series...
1. Mac
2. Sonos
3. reclocker
4. preamp/processor
The Sonos was modified so its clock could be slaved to the reclocker. The system has not one but TWO Audiocom Superclocks, one in the reclocker and one in the preamp/processor. That's a lot of $ just on clocks, but it's hard to argue with the results: Better clocks = less jitter = better SQ.
I'm not sure I have anything substantive to add to what Al and Steve have offered, but I think you're right that you will get a definitive answer only through experimentation. I'd be interested to hear what you discover.
Bryon |
If you wanted to go all out you could get the Zodiac Gold as a USB converter. This has USB in, AES/EBU out, and an external clock input. Throw in a $5K antelope atomic clock and you're in business. You can then use a reclocker on the Trinnov and the Zodiac. There may be cheaper USB to AES/EBU converters with external clock inputs.
Which begs the question. Steve, why aren't you building a version of the offramp with external clock input? This would alow synching up your converter with downstream digital processors with clock inputs. Not sure there is a huge market for this, but it is interesting concept that could redefine the state of the art. Could you custom build such a thing? I am talking way out of my techical comfort zone here so may be this is a nonsensical idea. But please enlighten me. |
You really need to add a Machina Dynamica "clever litte clock" if you want to take your system to upper reaches of perfection. |
Of course, a little research goes a long way - The hiFace EVO has all the features I need (external clock), AES/EBU out and is cheap. Wonder if the hiface + external clock would best a higher grade converter like the offramp, without ability to synch clocks with the Trinnov. I don't mind trial and error but having to take a $500 hardware write-off on each iteration. Better check those 30 day trial policies.... |
"Steve, why aren't you building a version of the offramp with external clock input? This would alow synching up your converter with downstream digital processors with clock inputs."
This would require a PLL or VCO clock. These have inherently higher jitter. There is no way that I could get to the jitter levels I achieve with these kinds of clocks. The clock must be free-running and stable.
Besides, the clocks in these DACs are not as good as the clock in my Off-Ramp 4. If you want to go inside the DAC and mod the clock and clock power supply, then maybe it would be competitive.
Steve N.
Empirical Audio |
Ed - Features dont equal performance, neither do parts. It's the whole package, including the implementation. What do you think JA uses?
Steve N.
Empirical Audio |
It would just be an alternative architecture - you'd have a pace-car, an offramp with no internal clock and a downstream DAC / processor. The pace-car would provide the clock for both the offramp and the downstream DAC / processor. May be the benefits of having the offramp and the DAC / processor on the same clock would outweigh the fact that the pace-car PLL clock is not the same quality as the internal clock of the offramp. |
ED - Adding a Pace-Car just complicates things. It would not improve the jitter. There is already a free-running master clock in the Off-Ramp 5.
The DAC is already a slave to the Off-Ramp 5, so the DAC is on the same clock, whether you use S/PDIF, AES/EBU, I2S or HDMI.
If you are talking about making the DAC the master and the source the slave, this would be worse. The clock in the DAC is just not good enough like I said, unless you mod it.
Steve N.
Empirical Audio |
