advertisement


Dummies guide to clocks and “re-clocking”

I have a dCS Puccini player, and given that the dCS Ring DAC was one of the original, groundbreaking high end DAC solutions, I must assume theirs is properly engineered. I also have the accompanying U-Clock, which makes a significant benefit to the sound, it is more organic and natural, like the difference between CD and SACD. dCS also advocate the use of an external clock, and it's a core part of their multi-box players.
 
Ive tried the Auralic Leo clock with my Aries / Vega combo and yes, it does make a positive difference to the SQ.
 
I'm amazed at companies who can't manage to get a decent clock signal a couple of cm across a pcb yet manage to pass it from one box to another intact.

Especially when not a single external clock review in any hifi press has yet shown a simple before and after jitter measurement improvement.

External clocks were necessary in studios to provide a central synced clock domain, they serve no purpose in hifi.
 
I tried a cuckoo clock with my dac and yes, it was a whole new ball game. This is a really good exposition ;)

 
Sloop John B said:
The OP just wanted to understand what clocking and reclocking was. I have a clearer view now. I think.

To test this....
So do most DACs have their own clock and in fact re-clock the signals they receive?

Or do most DACs rely on the clock from the “source”.
Click to expand...
To slightly expand on the reply from @sq225917 if it helps.

All DACs operating from SPDIF, TOSLINK or AES inputs rely on the source clock to some extent:
  • The worst ones generate their internal clock simply by following the external clock. I hope there are not many of these left.
  • The best ones re-clock by having an internal high quality clock circuit which gets synchronized to the average rate of the external clock but they suppress its jitter.
An external re-clocker of the right type might have a technical, possibly audible, effect with these inputs. But it might not.

For USB input I would pass over any DAC that did not do asynchronous USB because other USB types have the same "it depends" reliance on the incoming clock. For asynchronous USB the DAC's internal clock rules the conversion quality and an external re-clocker is unlikely to have any useful impact. But you still do need a high quality clock in the DAC.

Note that it looks quite possible that a DAC with SPDIF input and poor jitter suppression when fed with a source having a really good clock (e.g. from a re-clocker) may be better than one with asynchronous USB input and a poor internal clock. However my engineering senses shout at me that it's better to cure the fundamental problem at the DAC's point of conversion than to compensate upstream.
 
Why couldn't DACs operating from SPDIF, TOSLINK or AES use a small buffer and operate asynchronously? I thought this was fairly common.
 
Not sure id categorise it that way, asynchronous spdif....

Sure you can buffer/fifo reclock these, but its a much less popular approach than you might think which involves binning the entire clock and buffering large chunks of data. If the dac is described as an async upsampler then its probably doing this. Chord dacs, Cambridge Audio 840C etc.


Could have been more popular then high quality async usb came along and stole the market
 
booja30 said:
Why couldn't DACs operating from SPDIF, TOSLINK or AES use a small buffer and operate asynchronously? I thought this was fairly common.
Click to expand...
That's more-or-less what the good ones do.

A WM8805 receiver chip (for example) has a small elastic buffer and a rather nifty digital phase-locked loop that extracts the average clock rate from the incoming signal and controls a low-jitter local clock to keep it running at this average rate over the long term. That makes sure a finite-sized audio buffer's contents can go to the DAC chip in a timely fashion, tick by tick, without the buffer running out of data or overflowing.

This isn't actually asynchronous as the buffer would have to be of indeterminate size if it were.

Some DACs actually do operate asynchronously using an asynchronous sample rate converter (ASRC) which re-samples the incoming audio data to align it to the internal clock rather than the incoming clock.
 
So where would my Hugo TT fed by Auralic Aries (SPDIF) via m-scaler (dual BNC) be in these various scenarios?

.sjb
 
Dunno what's the connection, hi-res interleaved spdif alike over two wires just for bandwidth or something else?

Aiui the mscaler is just an upsampler, so I assume the above is true. Following best practice id assume a large fifo buffer and magically accurate local clock in the dac, just a few mm away from the dac chip.

Judging by the -170db jitter measurement...
 
I sort of wonder about all this re-clocking as there's a window of opportunity (propagation delay) within signals and clocks generally of about 10ns for rising or falling edges. All pretty standard stuff and the industry generally designs within limits that are understood. You'd have to make quite a hash of things of your design with the silicon available nowadays and it would all be pretty visible with a good scope.

I'd go with the 'forget about it and buy another album' brigade on this stuff...

I've got a WM8740 evaluation board kicking around somewhere if anyone wants to have a play and see for themselves.
 
Just buy a dac with jittter down -140db or better on your preferred input and forget about it.
 
booja30 said:
Why couldn't DACs operating from SPDIF, TOSLINK or AES use a small buffer and operate asynchronously? I thought this was fairly common.
Click to expand...
If you don't track the incoming rate, your buffer will overflow or run dry sooner or later.
 
Re the darko thing.

So basically what he's saying is if he removed the variability from his grinder, by using one with measured specifications, itd all be all right... well all he has to do is apply the same rigour to his hifi and he's sorted..

Ah but now he's reviewing a reclocker that then likely feeds an async dac that does its own reclocking, fail..
 
John Phillips said:
Some DACs actually do operate asynchronously using an asynchronous sample rate converter (ASRC) which re-samples the incoming audio data to align it to the internal clock rather than the incoming clock.
Click to expand...
An ASRC is just a way of converting clock error to data error. You still need a good PLL.
 
Asrc done well eliminates the timing errors by reclocking the samples. Jitter is just timing uncertainty converted to frequency error.
 
mansr said:
If you don't track the incoming rate, your buffer will overflow or run dry sooner or later.
Click to expand...
Yep, I wrote streaming server software 20 years ago, so that's pretty straightforward.

I don't understand how there are so many $$$ solutions to relatively easy problems. Then again, if you can convince someone they need something, you're in business.
 
You must log in or register to reply here.


advertisement


Back
Top