Clocks

[PaulB]

CG-10M Master Clock Generator

The TEAC CG-10M Master clock generator keeps precision time for digital-to-analog converters (DAC). Shop Now.

teacusa.com

Sold out at $1800. Not sure what "sold out" means - no more ever or currently out of stock.
Haven't heard it.

Teac has issued an End-Of-Life for that product and will announce a replacement model shortly.

****Dealer****

 

[Bruce B]

@Bruce B, what about in the case of multiple devices, like a switch and a streamer? If both have decently executed OCXOs, would sync'ing to an (equally good if not better) external clock be more advantageous?

Multiple items being used at the same time would benefit an external clock. Yes, if a source component does not have a great clock, then by all means, use the better one.

 

[thastum]

I added an extern clock from After dark with the best Giseman clockmodule to my streamer set up with great results.
The set up is a Esoteric N01 XD with top Sotm switch incl modification.
Before the Sotm i have the LHY SW 10 and the two switches are fiber connected over the SFP modules from Finsair.
50 ohm cabling are also from After dark so there is another upgrade path for the future.
Absolutely worth the investment as sq got much more lifelike and autentic in every way.

 

[Kingrex]

I don't have any internet in my room at the moment. I only have a server tied to the DAC. It's really good with near field listening. Good enough its better than my vinyl and tape were in the old room. At the moment, I can go without fiddling with a clock. But I'm still curious.

 

[analogsa]

Yes, if a source component does not have a great clock, then by all means, use the better one.

This may be oversimplifying it a bit. How exactly would a dac make use of a 10MHz clock? It is not generally a frequency dacs use internally. A dac which synthesises MCK/word clock out of a 10MHz clock relies on a pll circuit which already is a compromise. Or it may still rely on its internal clocks and use the external for reclocking. None of this sounds great to me, or perhaps I am missing something.

 

[Dustin Symanski]

This may be oversimplifying it a bit. How exactly would a dac make use of a 10MHz clock? It is not generally a frequency dacs use internally. A dac which synthesises MCK/word clock out of a 10MHz clock relies on a pll circuit which already is a compromise. Or it may still rely on its internal clocks and use the external for reclocking. None of this sounds great to me, or perhaps I am missing something.

With asynchronous sample rate conversion it would be possible to use 10Mhz directly in a DAC but I have never seen this done in practice. I also think that the algorithms that make asynchronous sample rate conversion possible are currently of rather low quality. Synchronous algorithms are nearly always superior. DACs circuits generally uses a clock such as 22.5792Mhz or in the case of an ESS based DAC 100Mhz or similar. To generate these frequencies from a 10Mhz clock you have a couple of choices, but they all have significant drawbacks. One issue with all of them is that the wideband jitter is completely dominated by the local clock circuit. Perhaps the best method is to use a local low phase noise Voltage Controlled Crystal Oscillator (VCXO) that is adjusted with a software controlled DAC until it is frequency matched to the 10Mhz source, this is also known as a Frequency Locked Loop (FLL). I like to use this system for transports which must be synchronous to a clock feedback channel from an external DAC. This is the lowest jitter method I know of for generating a DAC compatible clock from a 10Mhz source. However that same crystal oscillator circuit without the voltage control circuitry would have lower wideband jitter…. So the only thing you could possibly gain is frequency stability. Your effort would be much more effective increasing the stability of the DACs local clock instead, such as putting its oscillator in a thermally stable enclosure (known as an OCXO). Other possible circuits like analog (non-crystal based) PLLs or Frequency Synthesizers are all much higher jitter than a simple average “jellybean” crystal oscillators so they are not worth getting into their technical intricacies. In my view, if a product supports external clocks it had better be for a really! good reason, because the inevitable drawbacks of supporting them. The best reasons I can think of are, transports that need to be synchronous to the DACs they feed, and studio DACs and ADCs which need to be synchronized to function correctly as a coherent system.

 

[Tuckers]

In my view, if a product supports external clocks it had better be for a really! good reason, because the inevitable drawbacks of supporting them. The best reasons I can think of are, transports that need to be synchronous to the DACs they feed, and studio DACs and ADCs which need to be synchronized to function correctly as a coherent system.

 

[sbo6]

With the UTMOST respect to you and your decades of recording experience Bruce, it is not hard to find thousands of audiophiles who will differ with your assessment.

And probably just as many who agree with him.

 

[Mike Lavigne]

With asynchronous sample rate conversion it would be possible to use 10Mhz directly in a DAC but I have never seen this done in practice. I also think that the algorithms that make asynchronous sample rate conversion possible are currently of rather low quality. Synchronous algorithms are nearly always superior. DACs circuits generally uses a clock such as 22.5792Mhz or in the case of an ESS based DAC 100Mhz or similar. To generate these frequencies from a 10Mhz clock you have a couple of choices, but they all have significant drawbacks. One issue with all of them is that the wideband jitter is completely dominated by the local clock circuit. Perhaps the best method is to use a local low phase noise Voltage Controlled Crystal Oscillator (VCXO) that is adjusted with a software controlled DAC until it is frequency matched to the 10Mhz source, this is also known as a Frequency Locked Loop (FLL). I like to use this system for transports which must be synchronous to a clock feedback channel from an external DAC. This is the lowest jitter method I know of for generating a DAC compatible clock from a 10Mhz source. However that same crystal oscillator circuit without the voltage control circuitry would have lower wideband jitter…. So the only thing you could possibly gain is frequency stability. Your effort would be much more effective increasing the stability of the DACs local clock instead, such as putting its oscillator in a thermally stable enclosure (known as an OCXO). Other possible circuits like analog (non-crystal based) PLLs or Frequency Synthesizers are all much higher jitter than a simple average “jellybean” crystal oscillators so they are not worth getting into their technical intricacies. In my view, if a product supports external clocks it had better be for a really! good reason, because the inevitable drawbacks of supporting them. The best reasons I can think of are, transports that need to be synchronous to the DACs they feed, and studio DACs and ADCs which need to be synchronized to function correctly as a coherent system.

Dustin, a question:

if the stand alone MSB Select II dac is better with the 33 femto clock than the 77 femto clock? and i assume it is (mine had the 33 femto now standard). then why would another dac or transport with a standard clock not be improved by attaching a better one? assuming it was properly designed to take advantage of a better one?

i expect that manufacturers of this gear put clocks inside that make commercial sense (just like MSB), that there is a cost/benefit look see, but that maybe they offer the customer an upgrade path such as what you did with the Select II initially?

and i'm pretty ignorant of how these things work, so maybe i'm not even asking the right question. only that this thread exists because i bought a modest transport that i did not like how it sounded, then connected a clock i had already and the transport performance was transformed into something quite good and i was surprised. i'm just using an RCA S/PDIF interface with my dac. Kingrex read my posts and started to investigate clocks for himself.

 

[Dustin Symanski]

Dustin, a question:

if the stand alone MSB Select II dac is better with the 33 femto clock than the 77 femto clock? and i assume it is (mine had the 33 femto now standard). then why would another dac or transport with a standard clock not be improved by attaching a better one? assuming it was properly designed to take advantage of a better one?

I think I naively omitted basic architecture details that I thought people would pick up on or already were already familiar with. In my previous post I was talking about 10Mhz clocks, most circuitry does not use this frequency natively at all. USB generally uses a multiple of 24Mhz, Ethernet a multiple of 25Mhz, DVD based transports 27Mhz, CD players 11.2896Mhz, DACs and ADCs 24.576Mhz and 22.5792Mhz. So 10Mhz must be translated to “something else…” That translation is the problem addressed in my last post. The second detail is that all of our DACs, and the majority of high quality DACs, change their operational frequency based on the sample rate of the media. For example a 22.5792Mhz clock is used for 44.1Khz media and a 24.576Mhz clock is used for 96Khz media. If your external clock does not have two frequencies available then the receiving product must translate the clock or asynchronously sample rate convert the data, with all of the loss that translation entails. That translation is a more expensive, and a lower performance option than simply using a cheap jellybean crystal oscillators in the first place. Your external, ultra stable, super low jitter external clock is cut off at the knees by the clock conversion circuitry and is therefore irrelevant to performance of the product in question. In our DACs the oscillator is a dual frequency oscillator and it directly clocks the DACs, there is no translation. That clock is also sent back to the processors and back to the transport, renderer, USB, etc. In the case of the Cascade DAC it is sent back over fiber for use in the Digital Director, no translation necessary. The unused oscillator is also turned off to prevent coupling to the active oscillator. So if your DAC had an interface that sent the clock signal directly into the converters without any translation, and also had a control interface to select the correct operating frequency for the media being decoded then you would “only” have the loss incurred in the cabling and reception circuitry. However it would still be advantageous to put that same clock closer to the converters with less cabling and interference. In the case of a transport or other digital source the best option is to synchronize it with the DACs clock. This is optimally done by sending the DACs clock back to the transport. The industry standard for this is a “Word Clock” (a square wave at either 44.1Khz or 48Khz depending on the media). Our ProISL uses a more directly useful clock feedback frequency that is used to clock the data interface directly which results in even lower jitter and interference.

 

[Mike Lavigne]

I think I naively omitted basic architecture details that I thought people would pick up on or already were already familiar with. In my previous post I was talking about 10Mhz clocks, most circuitry does not use this frequency natively at all. USB generally uses a multiple of 24Mhz, Ethernet a multiple of 25Mhz, DVD based transports 27Mhz, CD players 11.2896Mhz, DACs and ADCs 24.576Mhz and 22.5792Mhz. So 10Mhz must be translated to “something else…” That translation is the problem addressed in my last post. The second detail is that all of our DACs, and the majority of high quality DACs, change their operational frequency based on the sample rate of the media. For example a 22.5792Mhz clock is used for 44.1Khz media and a 24.576Mhz clock is used for 96Khz media. If your external clock does not have two frequencies available then the receiving product must translate the clock or asynchronously sample rate convert the data, with all of the loss that translation entails. That translation is a more expensive, and a lower performance option than simply using a cheap jellybean crystal oscillators in the first place. Your external, ultra stable, super low jitter external clock is cut off at the knees by the clock conversion circuitry and is therefore irrelevant to performance of the product in question. In our DACs the oscillator is a dual frequency oscillator and it directly clocks the DACs, there is no translation. That clock is also sent back to the processors and back to the transport, renderer, USB, etc. In the case of the Cascade DAC it is sent back over fiber for use in the Digital Director, no translation necessary. The unused oscillator is also turned off to prevent coupling to the active oscillator. So if your DAC had an interface that sent the clock signal directly into the converters without any translation, and also had a control interface to select the correct operating frequency for the media being decoded then you would “only” have the loss incurred in the cabling and reception circuitry. However it would still be advantageous to put that same clock closer to the converters with less cabling and interference. In the case of a transport or other digital source the best option is to synchronize it with the DACs clock. This is optimally done by sending the DACs clock back to the transport. The industry standard for this is a “Word Clock” (a square wave at either 44.1Khz or 48Khz depending on the media). Our ProISL uses a more directly useful clock feedback frequency that is used to clock the data interface directly which results in even lower jitter and interference.

appreciate the details on optimal implementation approaches, but i'm no closer to an answer to my actual question (that "i" can discern from your response). but it's not your problem and i do thank you for your time. loved my time with my MSB.....and your team took great care of me.

 

[tony22]

@Dustin Symanski, this is great info but it makes me wonder even more - is there any real value in using a 10MHz clock to hook up to both a streamer (using I don’t know what clock frequencies) and a network switch (presumably a multiple of 25MHz)?

 

[AndrewChen]

Look for phase-noise specifications with any rubidium clock—I doubt you will find them.

Pretty easy to find. SRS Perf10. Rubidium Clock with Phase noise numbers even better than the Mutec REF10 SE120!

 

[Superdad]

Pretty easy to find. SRS Perf10. Rubidium Clock with Phase noise numbers even better than the Mutec REF10 SE120!

Nope. While the Stanford units are fine for their purpose, their phase-noise performance is quite mediocre.
From their datasheet it offers:
-130 dBc/Hz (10 Hz)
-140 dBc/Hz (100 Hz)
-150 dBc/Hz (1 kHz)
-155 dBc/Hz (10 kHz)
https://www.thinksrs.com/products/perf10.html

For audio, PN at low offsets is what matters, and -130dBc/Hz can be obtained from many under $1K OCXO-based clock boxes.
The $1,800 Mutec REF10 Nano gets you -142dBc/Hz at 10Hz and -158 at 100Hz. (-112 at 1Hz but SRS does not even proffer a spec at that low offset so comparison can not be made.) And the samples of Mutec we have measured here exceed their own specs by a 2-3dB at 1Hz and 10Hz.

 

[Holmz]

you need a "clock 50" cable. such as this one. it's very specific. with BNC's tuned to 50 ohms for a 10Mhz OCXO clock. 1 meter to 1.5 meter long i'm told is ideal. so proximity of the transport and clock is important.
….

Is ^that^ right?
I thought that 50 ohm cables usually terminate into a 50 ohm load, so that the cable is impedance matched.
Then the length doesn’t matter, and there are no reflections in the transmission line.

The “tuning” is not dine in the cable, but the drive and receive side are tuned to be 50 ohms.

 

[Mike Lavigne]

Is ^that^ right?
I thought that 50 ohm cables usually terminate into a 50 ohm load, so that the cable is impedance matched.
Then the length doesn’t matter, and there are no reflections in the transmission line.

The “tuning” is not dine in the cable, but the drive and receiver side are tuned to be 50 ohms.

thanks.

i'm no expert on clock 50 cable lengths, only related what i had heard. i have 2 of them; the Shunyata Sigma v2 clock 50 1 meter, and the Shunyata Omega clock 50 1.5 meter. the Omega is the higher level model and does sound better both on my transport and remarkably on my Esoteric T1 turntable. i was surprised that i could actually hear the effect of a better cable on the turntable. who knew?

i have no idea about the technology of clock 50 cables, just enjoying the result.

as far as the idea about length and 50 ohm, i have 17 years of 50 ohm BNC 'zeel' interconnect and the 50 ohm interface experience with darTZeel electronics. i've been told any length up to .5 kilometer is suppose to sound the same. i have no idea whether that is actually true. i know my 7.5 meter 50 ohm BNC's between my dart pre and dart amps does sound very fine. which the only thing i know as far as my listening experience.

 

[Holmz]

thanks.

i'm no expert on clock 50 cable lengths, only related what i had heard. i have 2 of them; the Shunyata Sigma v2 clock 50 1 meter, and the Shunyata Omega clock 50 1.5 meter. the Omega is the higher level model and does sound better both on my transport and remarkably on my Esoteric T1 turntable. i was surprised that i could actually hear the effect of a better cable on the turntable. who knew?

i have no idea about the technology of clock 50 cables, just enjoying the result.

as far as the idea about length and 50 ohm, i have 17 years of 50 ohm BNC 'zeel' interconnect and the 50 ohm interface experience with darTZeel electronics. i've been told any length up to .5 kilometer is suppose to sound the same. i have no idea whether that is actually true. i know my 7.5 meter 50 ohm BNC's between my dart pre and dart amps does sound very fine. which the only thing i know as far as my listening experience.

I am talking about theory and why the 50 and 75 ohm cables came into being ~100 years ago.

What we hear is not always the same as theory.

 

[Republicoftexas69]

Nope. While the Stanford units are fine for their purpose, their phase-noise performance is quite mediocre.
From their datasheet it offers:
-130 dBc/Hz (10 Hz)
-140 dBc/Hz (100 Hz)
-150 dBc/Hz (1 kHz)
-155 dBc/Hz (10 kHz)
https://www.thinksrs.com/products/perf10.html

For audio, PN at low offsets is what matters, and -130dBc/Hz can be obtained from many under $1K OCXO-based clock boxes.
The $1,800 Mutec REF10 Nano gets you -142dBc/Hz at 10Hz and -158 at 100Hz. (-112 at 1Hz but SRS does not even proffer a spec at that low offset so comparison can not be made.) And the samples of Mutec we have measured here exceed their own specs by a 2-3dB at 1Hz and 10Hz.

Is there a clock that you found to have the performance to cost ratio and will make a difference in most systems? Looks as if you recommend the Mutec?

 

[SCAudiophile]

Pretty easy to find. SRS Perf10. Rubidium Clock with Phase noise numbers even better than the Mutec REF10 SE120!

Note: I am not a Mutec owner of the REF120SE or any other of their models...

SRS does not quote at 1Hz, and their phase noise numbers while very good from 10 Hz on up, are not better than the Mutec REF120SE nor is their Allan behavior better than the Mutec from what I can see...

I'm open to correction if someone sees an erroneous interpretation of these.

 

[Elberoth]

+1

All those Rubidum clocks are waste of money. Good, but not great performance and can be easily equalled by units with quality OCXO oscillators costing 1/10 of the price.

I'm surprised anyone is buing those, but I guess the words "Rubidium" and "Atomic" still apeal to many audiophiles.

Look for clocks from CyberShaft (Japan) or Mutec. I had both, but recommend Mutec to friends, simply 'cos Mutec is a much bigger manufacturer with wider distribution, more features and better availability (CyberShaft clocks are made more or less to order and wait times may go into weeks or even months).

PS. Jcat card uses custom 20MHz clock, so any of those 10MHz clocks will not work.