Upgrading a DAC clock is a fool’s errand.

Tam Lin

Well-Known Member
Mar 20, 2011
108
44
933
North Texas
You can buy and install a so-called femto-clock but the clock signal that reaches the DAC chips is more likely a pico- or a nano-clock. The reason is the intervening logic gates used to select and divide the oscillator’s output to provide different bit- and word-clock rates as required.

Thirty years ago, I worked for a startup in the mainframe business. I was one of only a few programmers there and I was surrounded by dozens of the best digital hardware engineers in the business. The most often heard topics of conversation in the hallways and conference rooms pertained to clock distribution and signal integrity. Clocks were treated with great respect because the slightest perturbation would jeopardize the entire system. The chief engineer was fond of riddles. I remember one that asks, "When is a clock not a clock? … When it passes through combinatorial logic."

Blizzard proposes reclocking as a cure for all that ails USB audio. At the heart of any reclocking scheme is a latch. In its simplest form a latch is logic gate with two inputs, clock and data, and one output, data. It is used to capture the state of the input data at the instant the clock changes state, usually the rising edge. The output of a latch is data; not a clock.

Most USB DACs have two oscillators, one for sample rates that are multiples of 44.1K and the other for multiples of 48K. In most cases the oscillators are always running, each taking gulps of current from a common power supply and leaving behind a residue of their respective clock rates. The crème de la crème DACs use oven controlled oscillators (OCXO) because they are the most stable. However, OCXOs are always on and their output cannot be turned off. To select which oscillator is used to clock the DAC chips the circuit uses a multiplexor (mux). In its simplest form a mux has three inputs, one selector, two data, and one output, data. The selector signal chooses which input data is passed to the output. Now, the two pristine OCXO ‘femto’ clocks are dumped onto the same silicon substrate and pass, side-by-side, through a common logic gate, the mux.

The comical part is when the selected ‘femto’ clock crosses a galvanic isolation barrier to enter the dragon’s den, as it were, where is mingles with the CPU that manages the USB bus protocol. There it is divided down and joined with the sample data and sent back across the galvanic barrier and then on to the DAC chips. It's hard to imagine a worse digital audio interface.
 
Our precious digital recordings have been made using ADCs that used clocks that probably did not care about the femto second or probably the pico second, and did not exhibit certificates of ultra low phase noise. This means that some kind of jitter is already embedded in the recording. We are always listening to the combined effects of two jitter sources - the ADC and DAC clocks.
 
Good write-up Tam.

Manufacturers tend to take advantage of what us as consumers understand about clocks which is accuracy. In reality, accuracy is not an issue. If your music played 0.001% slower or faster would you care? I suspect not.

What we care about in DAC clocks is variations. Those variations modulate the clock back and forth. Those modulations if below 20 Khz fall in the audio band. And can therefore be audible regardless of the clock source being more accurate than an atomic clock or not.

Those variations as you imply, can come from many sources such as the power supply or couple through the "air" from adjacent logic. And nothing is more noisier than compute running networking protocols.

BTW, digital designers care about very different things than we do. In the case of clock distribution their biggest concern is clock skew where the edges of the clock are different from one point to another point in the circuit. This can rob you of "timing margin" and eventually result in failed logic. That is probably what your gray haired hardware expert was talking about as far as kew increasing once you route the clock through combinational logic. Fortunately our digital paths are pretty simple in DACs and our circuits do not operate at high speeds or tight margins so this is not a concern for us.
 
On the issue of jitter in ADC, it is much less of an issue than in DAC. For one thing, whatever audible effect it may have created, the talent heard and approved that sound. And since our goal is to hear what was heard in the studio, then that has to be definition be fine. After all, a lot of instruments have distortions in themselves and their amps, mics, etc. We don't worry about those so why worry about ADC jitter in that regard. Of course one hopes that they use good ADCs and have good ears to know the difference. But if they don't, jitter will be the least of our problems in those recordings :).

Second, an ADC is not trying to chase the clock from a source. It is the master and in charge of its own clock. It is a much simpler scheme that us trying to either sync to a source clock or create an async clock and keep all of its digital noise away from our DAC.
 
(...) Manufacturers tend to take advantage of what us as consumers understand about clocks which is accuracy. In reality, accuracy is not an issue. If your music played 0.001% slower or faster would you care? I suspect not.
(...)

We still have the same issue in turntable debates ... What matters is precision, not accuracy.
 

Attachments

  • a1.jpg
    a1.jpg
    38.2 KB · Views: 1,839
The comical part is when the selected ‘femto’ clock crosses a galvanic isolation barrier to enter the dragon’s den, as it were, where is mingles with the CPU that manages the USB bus protocol. There it is divided down and joined with the sample data and sent back across the galvanic barrier and then on to the DAC chips. It's hard to imagine a worse digital audio interface.


You are right, that sounds like a horrible way to implement a reclocking system. Please share an example of such a system so the readers can avoid it like the black plague. Pictures will help to clarify as well.
 
Last edited:
Swenson clock primer:
JohnSwenson JohnSwenson is offline
Sophomore Member
Join Date
Jun 2009
Posts
427
Quote Originally Posted by gldgate View Post
A quick follow up to my last post. It's important to note that the digital signal from the PC will be reclocked by the TCXO clocks in the U8 and not the VCXO's in the Yggy. While I am not an expert in clocks it appears that TCXO's are more accurate than VCXO's (and OCXO's are even more accurate still).
OK here goes, some (hopefully) short on crystal oscillators.

A crystal oscillator uses a hunk of piezoelectric material and puts metal plates on opposite side and puts it in an electrical feedback loop. The crystal actually changes shape as current flows through, this changes its electrical properties. The feedback loop is setup so this causes an oscillation. (the crystal alternating getting smaller and larger). The frequency at which it does this is primarily determined by the physical dimensions of the crystal. The capacitance in the electrical circuit also has a small affect on the frequency.

The temperature of the crystal has a significant affect on the frequency, the material changes size as the temperature varies.

There are several different parameters of an oscillators frequency performance.

initial frequency tolerance
long term frequency drift
temperature coefficient (how much change per a given change in temperature)
and short term frequency changes.

The initial frequency tolerance will usually be stated as so many ppm (parts per million). Thus if you have an oscillator whose nominal frequency is 1MHz, 10 ppm means it can be off by 10HZ and be with in spec.

All crystals will slowly change with time. After a few years their frequency might change significantly more than the initial tolerance.

For applications that need a very accurate frequency the temperature coefficient cam be very critical. Several methods have been developed over the years to address this.

Short term frequency change is frequently referred to as jitter. I'm sure you have heard of it. Rapid changes in frequency (high jitter) can have significant impact on audio.

For a DAC, changes to the frequency (jitter) are usually far more important than the absolute value of the frequency. Thus an oscillator with very low jitter, but whose frequency is 20ppm off from the "official" value will usually sound much better than an oscillator with high jitter, but whose actual frequency is only 5 ppm from the official value.

Thus as far as I am concerned methods to decrease the temperature coefficient unless they also decrease jitter are pretty much useless, and mean you are spending money on something that is not going to help sound quality.

I'm going to go over what some of the oscillator types are and what those acronyms mean.

A VCXO is a Voltage Controlled Crystal Oscillator. It uses a voltage fed into a varactor diode to change the frequency of the oscillator (frequently called "pulling" the frequency). The varactor diode changes capacitance as its voltage is varied, thus slightly changing the frequency of the oscillator. Any noise on the control voltage will result in a varying frequency otherwise known as jitter. Thus a VCXO will always have higher jitter than a basic crystal oscillator of the same build (crystal quality, electronics etc).

A TCXO is a Temperature Compensated Crystal Oscillator. It is a VCXO driven by a temperature sensor. Since it is a VCXO you get higher jitter in order to get the lower temperature coefficient. So one number gets better, the parameter which has a higher impact on sound gets worse, not a good tradeoff as far as I am concerned.

This does not mean that all TCXOs are bad, but for a given jitter you can achieve it for a lot less money with a regular XO. Very well done (and costly) TCXOs will have lower jitter than cheap XOs, but a well done XO will have lower jitter than an equivalently priced TCXO.

OCXO is Oven Controlled Crystal Oscillator. The whole oscillator is placed in a small oven with a very tight control loop on the temperature to keep it very stable. Not only is the temperate very stable, but at a certain temperature the temperature coefficient goes to zero. Thus an OCXO can achieve essentially zero temperature coefficient. This isn't cheap, it costs a lot of money to do this well, so most OCXOs use very good oscillators to begin with. The result is that most OCXOs usually have very low jitter, not because of the oven part, but because by the time you spend a lot of money on the oven, you might as well spend a fair amount on the XO to begin with. Again you're spending a LOT of money on something you don't need. You do get low jitter, but you could spend a lot less money to get that level of jitter from a basic XO.

The problem is that it is usually hard to find a basic XO module with the really low levels of jitter, the manufacturers would rather sell you the very expensive OCXO so really low jitter XOs are hard to find.

John S.
 
Swenson re Galvanic isolation:
The isolation between computer and DAC was not a primary focus of what I am talking about now. Test I did seem to show this is not as big an issue as many previously supposed.

This post is primarily about the impact of the PDN on the generation of PS noise at sensitive chips in a DAC(main oscillator, DAC chip). In particular how a packetized data delivery (USB, Ethernet) significantly exacerbates this. Primarily because the packetized system produces current through the PDN with a much greater bandwidth than non-packetized systems (say I2S). Producing PDN to work well over this wide bandwidth is MUCH harder than for a non-packetized system.

On the question of WiFi: it is also a packetized system, and because of all the processing going on in WiFi, probably much worse than straight wired Ethernet.

On isolation, I have been including full isolation between digital sections and mixed signal sections for many many years. I do not use optical isolators, I do not like them at all, I prefer the GMR (Giant Magneto Resistive) isolators made by NVE. I think they work way better than opto isolators.

The important question here is how come an isolator doesn't completely fix things, it seems at first glance that having completely isolated power networks for the digital side and the mixed signal side (I'm calling it mixed signal because there are digital signals (I2S data, clocks) AND analog signals (output from the DACchips) in the same power domain) should prevent PS noise from going between them. If the power domains were truly isolated they would, BUT the domains are NOT completely isolated, the data is going between them! This is the part that is usually forgotten in these types of discussions.

I hope I can convey what is happening here, let's follow a pulse through an isolator between domains and see what happens. Let's assume a real "dirty" digital side, a lot of ground plane noise and power supply noise, and noise riding on top of the digital signal. Lets look at the isolator, it has power and ground connections on the "dirty" side that run the driver that produces the whatever crosses the "barrier" (light, magnetic field, radio waves, whatever). The noise also modulates the "threshold" looking at the input signal. These and the noise and jitter in the signal all add up to a pretty large amount of variation in the field crossing the barrier.

On the other side of the barrier you have a much cleaner supply driving the receiver circuit, but the noisy field is going to cause a current in the receiver. Thus noise on the dirty side is going to cause current noise on the clean side as well. The isolator designers try and make them so the physical properties of the receivers have some form of thresholding so this transmitted noise is decreased, but a fair amount still gets through, and it is greater at the low frequency side. But that is not all, the data, the signal you WANT to cross the barrier, also causes current to flow through the PS pins of the clean side of the isolator, and that signal has a lot of jitter on it by now.

When the packet noise on the dirty side of the barrier is low, the current noise of the isolator will be lower, when the packet noise is high, the current noise of the isolator will be high. So even though the power supplies are completely separate, packet noise on the dirty side can still make it through an isolator and show up as current noise on the "clean side". If the PDN is very low impedance over a very wide bandwidth this current noise will produce very little voltage noise. If the PDN is not so great, there will be some significant voltage noise. It usually will be reduced from what it was on the dirty side, but still definitely there.

Yes putting a whole tracks worth of data in ram, shutting down the packet interface, and grabbing the data out of ram at the audio sample rate should help this, but this is frequently done by a processor and it's memory, that processor is usually producing it's own set of current noise which can cross the barrier. To be really effective it would take a system where the source (whatever it is) fills up the buffer then completely shuts down, nothing drawing power AT ALL from then on, the only thing drawing power is the counter walking through the ram and the ram itself. You definitely would want a simple ram structure, not something like a DDR3 DIMM which has all kinds of stuff going on all the time. The data from the RAM goes over the isolator and on to the DAC chip. This would probably be a very effective isolation scheme, but I don't think anybody has actually ever implemented this.

I have been doing some more experiments on this in the last week and have some results to share. I was working with the USB regen Alex mentioned, with the first version I was able to clearly see the packet noise on a scope. I made a new version with an improved PDN, this seemed to work, I could not see any packet noise any more, noise was still there but I could not discern any modulation due to the packet frequency. It sounded significantly better. Later I did some crude PDN analysis and discovered there was a raising in the impedance over a certain frequency range. I figured out I could fix this by adding a single capacitor in the right place. I soldered in that cap and started listening and was startled in the magnitude of the improvement in SQ. The noise looked identical with and without the capacitor, the sound significantly improved.

So I think I am on the right track, but it looks like I have already gone beyond what the simple measurements I was doing could detect. Next is to do these tests with the spectrum analyzer, it will probably be able to detect the packet noise buried in the over all noise floor.

I hope that answers some of the questions.

John S.
----------------

Galvanic isolation thread here: http://www.computeraudiophile.com/f...evices-isolation-22048/index4.html#post362677
 
(...)
The problem is that it is usually hard to find a basic XO module with the really low levels of jitter, the manufacturers would rather sell you the very expensive OCXO so really low jitter XOs are hard to find.
(...)

In the old days people did not buy ??XO modules, they designed low jitter discrete oscilators using crystals, transistors, RF FETs or ECL gates. A lost art?
 
The problem is that it is usually hard to find a basic XO module with the really low levels of jitter, the manufacturers would rather sell you the very expensive OCXO so really low jitter XOs are hard to find.

John S.


Yes, very hard to find if you live deep in the forest, without an internet connection.
 
Swenson re Galvanic isolation:
The isolation between computer and DAC was not a primary focus of what I am talking about now. Test I did seem to show this is not as big an issue as many previously supposed.

This post is primarily about the impact of the PDN on the generation of PS noise at sensitive chips in a DAC(main oscillator, DAC chip). In particular how a packetized data delivery (USB, Ethernet) significantly exacerbates this. Primarily because the packetized system produces current through the PDN with a much greater bandwidth than non-packetized systems (say I2S). Producing PDN to work well over this wide bandwidth is MUCH harder than for a non-packetized system.

On the question of WiFi: it is also a packetized system, and because of all the processing going on in WiFi, probably much worse than straight wired Ethernet.

On isolation, I have been including full isolation between digital sections and mixed signal sections for many many years. I do not use optical isolators, I do not like them at all, I prefer the GMR (Giant Magneto Resistive) isolators made by NVE. I think they work way better than opto isolators.

The important question here is how come an isolator doesn't completely fix things, it seems at first glance that having completely isolated power networks for the digital side and the mixed signal side (I'm calling it mixed signal because there are digital signals (I2S data, clocks) AND analog signals (output from the DACchips) in the same power domain) should prevent PS noise from going between them. If the power domains were truly isolated they would, BUT the domains are NOT completely isolated, the data is going between them! This is the part that is usually forgotten in these types of discussions.

I hope I can convey what is happening here, let's follow a pulse through an isolator between domains and see what happens. Let's assume a real "dirty" digital side, a lot of ground plane noise and power supply noise, and noise riding on top of the digital signal. Lets look at the isolator, it has power and ground connections on the "dirty" side that run the driver that produces the whatever crosses the "barrier" (light, magnetic field, radio waves, whatever). The noise also modulates the "threshold" looking at the input signal. These and the noise and jitter in the signal all add up to a pretty large amount of variation in the field crossing the barrier.

On the other side of the barrier you have a much cleaner supply driving the receiver circuit, but the noisy field is going to cause a current in the receiver. Thus noise on the dirty side is going to cause current noise on the clean side as well. The isolator designers try and make them so the physical properties of the receivers have some form of thresholding so this transmitted noise is decreased, but a fair amount still gets through, and it is greater at the low frequency side. But that is not all, the data, the signal you WANT to cross the barrier, also causes current to flow through the PS pins of the clean side of the isolator, and that signal has a lot of jitter on it by now.

When the packet noise on the dirty side of the barrier is low, the current noise of the isolator will be lower, when the packet noise is high, the current noise of the isolator will be high. So even though the power supplies are completely separate, packet noise on the dirty side can still make it through an isolator and show up as current noise on the "clean side". If the PDN is very low impedance over a very wide bandwidth this current noise will produce very little voltage noise. If the PDN is not so great, there will be some significant voltage noise. It usually will be reduced from what it was on the dirty side, but still definitely there.

Yes putting a whole tracks worth of data in ram, shutting down the packet interface, and grabbing the data out of ram at the audio sample rate should help this, but this is frequently done by a processor and it's memory, that processor is usually producing it's own set of current noise which can cross the barrier. To be really effective it would take a system where the source (whatever it is) fills up the buffer then completely shuts down, nothing drawing power AT ALL from then on, the only thing drawing power is the counter walking through the ram and the ram itself. You definitely would want a simple ram structure, not something like a DDR3 DIMM which has all kinds of stuff going on all the time. The data from the RAM goes over the isolator and on to the DAC chip. This would probably be a very effective isolation scheme, but I don't think anybody has actually ever implemented this.

I have been doing some more experiments on this in the last week and have some results to share. I was working with the USB regen Alex mentioned, with the first version I was able to clearly see the packet noise on a scope. I made a new version with an improved PDN, this seemed to work, I could not see any packet noise any more, noise was still there but I could not discern any modulation due to the packet frequency. It sounded significantly better. Later I did some crude PDN analysis and discovered there was a raising in the impedance over a certain frequency range. I figured out I could fix this by adding a single capacitor in the right place. I soldered in that cap and started listening and was startled in the magnitude of the improvement in SQ. The noise looked identical with and without the capacitor, the sound significantly improved.

So I think I am on the right track, but it looks like I have already gone beyond what the simple measurements I was doing could detect. Next is to do these tests with the spectrum analyzer, it will probably be able to detect the packet noise buried in the over all noise floor.

I hope that answers some of the questions.

John S.
----------------

Galvanic isolation thread here: http://www.computeraudiophile.com/f...evices-isolation-22048/index4.html#post362677

That's a great post explaining John's level of understanding at the time of his post. But it doesn't explain much about the level of understanding others are at, who have been refining their reclocker systems for years.
 
Last edited:
These diagrams show how the oscillator can be connected to the DAC clock. The oscillator frequency is chosen to match the sweet spot of the DAC and the music is resampled to that rate. Obviously, the USB connection does not use isochronous transfer mode.

fixed.png
 
Here is a summary of my current project that implements direct clock connection, among other things.

Highlights:
* 44.1K to 24.576M sample rate.
* Thirty-two PCM1704K per channel.
* No logic gates between oscillator and DACs.
* Transformer output stage with M/S decoding.
* PC software resamples and applies M/S encoding.

USB 3.0 connection uses bulk transfer, which bypasses the entire PC audio sub­system and insures error-free data delivery. The receiver interface is a FIFO. The input side is buffered; the PC immediately fills empty buffers. The output side transfers word clock and sample data to the DACs.

A micro­processor oversees USB initialization and buffer management. It also selects the oscillator and reconstruction filter based on the track’s metadata. In fact, metadata can alter most DAC and player configuration settings. This simplifies A/B testing and allows custom con­fig­urations for individual tracks.

Native sample rates are 705.6K and 768K. For input at or below the native rate, the DACs operate in parallel. Below the native rate, the player inserts nulls to stretch the sample period. Above the native rate, the DACs are staggered and the data at each point is the input sample value minus the sum of the data in the other DACs. Thus, each successive sample is the 24-bit delta needed to reach the next sample point.

Foobar 2000 maintains the music library and fetches the samples and the metadata for the selected track. However, instead of playing the track, a covert DSP plugin hijacks the data and passes it to an external 64-bit process. There libsoxr resamples and another process reorders the data bits before passing them to the FX3 device driver and thence to the DACs.

schem.png
 
Here is a summary of my current project that implements direct clock connection, among other things.

Highlights:
* 44.1K to 24.576M sample rate.
* Thirty-two PCM1704K per channel.
* No logic gates between oscillator and DACs.
* Transformer output stage with M/S decoding.
* PC software resamples and applies M/S encoding.

USB 3.0 connection uses bulk transfer, which bypasses the entire PC audio sub*system and insures error-free data delivery. The receiver interface is a FIFO. The input side is buffered; the PC immediately fills empty buffers. The output side transfers word clock and sample data to the DACs.

A micro*processor oversees USB initialization and buffer management. It also selects the oscillator and reconstruction filter based on the track’s metadata. In fact, metadata can alter most DAC and player configuration settings. This simplifies A/B testing and allows custom con*fig*urations for individual tracks.

Native sample rates are 705.6K and 768K. For input at or below the native rate, the DACs operate in parallel. Below the native rate, the player inserts nulls to stretch the sample period. Above the native rate, the DACs are staggered and the data at each point is the input sample value minus the sum of the data in the other DACs. Thus, each successive sample is the 24-bit delta needed to reach the next sample point.

Foobar 2000 maintains the music library and fetches the samples and the metadata for the selected track. However, instead of playing the track, a covert DSP plugin hijacks the data and passes it to an external 64-bit process. There libsoxr resamples and another process reorders the data bits before passing them to the FX3 device driver and thence to the DACs.

View attachment 24048

Sounds good. Let us know when it's ready. Any plans to build a general purpose USB interface board?
 
In reality, accuracy is not an issue. If your music played 0.001% slower or faster would you care? I suspect not.

Spoken like a tone-deaf audiophile. A significant feature of my project is the ability to fine-tune the oscillator, VCXO or DPLL, to correct the pitch of a recording and store the correction factor in the file tags so the same correction can be applied each time the track is played.
 
Spoken like a tone-deaf audiophile.
I am and proud of it:

music-audition-sings-auditioning-talent_show-singing-ksmn2436_low.jpg


A significant feature of my project is the ability to fine-tune the oscillator, VCXO or DPLL, to correct the pitch of a recording and store the correction factor in the file tags so the same correction can be applied each time the track is played.
And you would know the pitch of the original recorded music how?
 

About us

  • What’s Best Forum is THE forum for high end audio, product reviews, advice and sharing experiences on the best of everything else. This is THE place where audiophiles and audio companies discuss vintage, contemporary and new audio products, music servers, music streamers, computer audio, digital-to-analog converters, turntables, phono stages, cartridges, reel-to-reel tape machines, speakers, headphones and tube and solid-state amplification. Founded in 2010 What’s Best Forum invites intelligent and courteous people of all interests and backgrounds to describe and discuss the best of everything. From beginners to life-long hobbyists to industry professionals, we enjoy learning about new things and meeting new people, and participating in spirited debates.

Quick Navigation

User Menu