Wordclock vs Superclock

[audiox]

We talked about this with a friend of mine yesterday but didn't find the answer.

Wordclock (and AES11) syncronise digital audio equipment so that frames of AES, SPDIF etc. signals start at the same time (with certain accurary). Rising edge of wordclock means start of frame and one full wordclock cycle is equal to one frame.

There is however so called superclock (used in Pro tools) that is 256 x Fs (wordclock). When wordclock unambiguously defines the start of frame, superclock has 256 alternatives (rising edges) for that. So it can't be used to define the start of frame.

Where do I go wrong? Isn't that important anymore to define start of frame when syncronising audio equipment?

 

[abbey road d enfer]

Superclock is not used on its own, always in conjunction with standard WC.
Superclock offers the advantage of avoiding PLL's.
When you sync with WC only, the receiver has to reconstruct the Master clock (256, 384, 512x) from where the bit clock (64x) is derived. Since most modern converters start with high speed conversion (higher than 64x) at reduced resolution (5-8 bits) followed by decimation, which trades speed for resolution, the stability (low jitter) of the Master clock is paramount. If you sync with WC only, the receiver processes it with a PLL that produces the Master clock and its derivatives (primary sampling clock, bit clock). A PLL inherently suffers from jitter.
If you sync with WC and Superclock, the primary sampling clock and bit clock are derive by simple division, which is an almost jitterless process.

 

[audiox]

Superclock is not used on its own, always in conjunction with standard WC.

I was thinking that alternative too, but I didn't find it in the Pro tools manuals that were available for download. Thanks.

 

[playboss]

which converters have 8bit quantizer? BTW i have a lynx aes with super clock input, but ivebeen told its still routed into the PLL system...

 

[abbey road d enfer]

which converters have 8bit quantizer?

I don't really know. This information is difficult to find. You have to read the full datasheet of the TI PCM4222 to find out the primary converter is 6 bit. It is almost impossible to find this information from Cirrus Logic or Wolfson datasheets. Regarding those with 8 bit, I only had a hint when I recently read an ad for a new ADC that claimed using an 8 bit sigma/delta, but I don't remember what brand it was.

BTW i have a lynx aes with super clock input, but ivebeen told its still routed into the PLL system...

That's very strange, and denies the benefits of using a Masterclock, unless they think their PLL has less jitter than the incoming MC.

 

[playboss]

http://www.msbtech.com/support/JitterPaper.pdf

these guys swapped the clock entirely on the lynx card, i suppose thats the way to go )

Big quantizer resolution might not be that necessary , but theoretically it'd help to achieve lower levels of ultrasonic crud i guess, and thats something AKM used to be proud of. The latest converters by ESS can be set to have 9bits when all channels are summed, this makes IV conversion problematic and returns are minimal, sound might be not all that different compared to a single bit PWM dac IMHO... We can hear no difference between 6 / 8bits ...

 

[jdbakker]

BTW i have a lynx aes with super clock input, but ivebeen told its still routed into the PLL system...

That's very strange, and denies the benefits of using a Masterclock, unless they think their PLL has less jitter than the incoming MC.

I should hope so.

It's non-trivial to send a 12-24MHz clock between two units without adding more jitter than a good PLL+VCXO would. You can't have transitions that are as fast as an intra-box connection would have, you want galvanic isolation to deal with ground loops and the like, and RF transformers pick up magnetic hum from power transformers too. Proper clock distribution is hard, and unless you need very tight phase relations (think phased antenna arrays) or a clock that sweeps from one frequency to another putting in a simple PLL with low loop bandwidth is a much safer choice. Feeding said PLL a 10+MHz sample clock rather than a 44+kHz word clock helps lower phase noise.

JDB.
[and once you have a PLL, you can invert one cycle of your clock Manchester-encoding style to indicate the start of your sampling period. Dunno whether Digi does this, but I would]

 

[abbey road d enfer]

http://www.msbtech.com/support/JitterPaper.pdf

these guys swapped the clock entirely on the lynx card, i suppose thats the way to go )

It is debatable; they're trading continuous low level artefacts against large spurious ones. At the movies, would you rather have a scratchy or wobbling picture or a picture that altogether disppears from time to time?

 

[abbey road d enfer]

BTW i have a lynx aes with super clock input, but ivebeen told its still routed into the PLL system...

That's very strange, and denies the benefits of using a Masterclock, unless they think their PLL has less jitter than the incoming MC.

I should hope so. It's non-trivial to send a 12-24MHz clock between two units without adding more jitter than a good PLL+VCXO would. You can't have transitions that are as fast as an intra-box connection would have, you want galvanic isolation to deal with ground loops and the like, and RF transformers pick up magnetic hum from power transformers too.

No one said it was trivial, but it is theoretically possible to create a jitterless connection, when a PLL is bound to introduce jitter, especially if it's "a simple one with low loop bandwidth". By definition , a PLL is constantly bouncing between lead and lag, which is a good definition of unstability.

Proper clock distribution is hard, and unless you need very tight phase relations (think phased antenna arrays) or a clock that sweeps from one frequency to another putting in a simple PLL with low loop bandwidth is a much safer choice. Feeding said PLL a 10+MHz sample clock rather than a 44+kHz word clock helps lower phase noise.

It was confusing because Playboss' post seemed to indicate that the main PLL was still involved when using Superclock. BTW, meantime I've checked the Lynx website and there is no indication that the AES card has a Superclock input. Using a PLL on a Superclock input is replacing a possibly non-existent jitter with one that's bound to exist.

[and once you have a PLL, you can invert one cycle of your clock Manchester-encoding style to indicate the start of your sampling period. Dunno whether Digi does this, but I would]

And that's how you unescapably create jitter...and thus justifies the PLL
[/quote]

 

[playboss]

it definately has superclock input, its in the manual ;D Whatever, Im sold on the ASRC concept and i saw actual measurements , it discards jitter entirely, similar to MSB's results... As DAW's are already using high sampling rates , its sound quality "hit" must be negligible and theres no need for sync/clock trickery any more.

 

[jdbakker]

it is theoretically possible to create a jitterless connection

Even in theory your interconnect has nonzero resistance and will add noise and thus threshold uncertainty and jitter. In practice going between two boxes adds quite a bit of conducted and radiated interference, never mind inevitable nonlinearities in your transmitter and receiver circuitry. You can try to reduce this by having sharper edge transitions and/or higher signal amplitude, but both will make it harder to get your equipment through EMI testing. If you know of a nice, clean, user-serviceable way to distribute a low-jitter clock over several boxes in the same rack then I (and quite a few other RF engineers) would love to hear about it.

[...] a PLL is bound to introduce jitter, especially if it's "a simple one with low loop bandwidth". By definition , a PLL is constantly bouncing between lead and lag, which is a good definition of unstability.

I'm sorry, there were a few hidden assumptions there which I should have mentioned explicitly. For me, 'low loop bandwidth' means <<1Hz. As that is hard to do properly in an analog system (mostly due to capacitor imperfections) almost all such systems that I've worked with were digital PLLs, with either a microcontroller or a CPLD driving a DAC to the CV input of the VCXO. Again, almost all such systems have a 'hold' feature where they keep the control voltage constant when the phase detector output stays close enough to zero for a programmable length of time.

[quote author=jdbakker][and once you have a PLL, you can invert one cycle of your clock Manchester-encoding style to indicate the start of your sampling period. Dunno whether Digi does this, but I would]

And that's how you unescapably create jitter...and thus justifies the PLL[/quote]

You only do this when you already have a PLL, of course, not the other way around.

JDB.

 

[abbey road d enfer]

it is theoretically possible to create a jitterless connection

Even in theory your interconnect has nonzero resistance and will add noise and thus threshold uncertainty and jitter. In practice going between two boxes adds quite a bit of conducted and radiated interference, never mind inevitable nonlinearities in your transmitter and receiver circuitry.

I agree with that, noise is inevitable, just as it is in a PLL. But intrinsically, transmitting a clock on a cable is not a source of jitter, whereas a PLL is.

  You can try to reduce this by having sharper edge transitions and/or higher signal amplitude, but both will make it harder to get your equipment through EMI testing. If you know of a nice, clean, user-serviceable way to distribute a low-jitter clock over several boxes in the same rack then I (and quite a few other RF engineers) would love to hear about it.

The real question is, which one is best, according to the requirements. PLL recovery has better jitter figures, because the measurement process averages the results over a period of time. A PLL such as the one you describe has periods of freewheeling (with theoretical intrinsic zero phase noise) separated by "violent" nudges forward or backward depending on the lag or lead. I don't claim one is best than the other; I just say there's no free meal. A PLL isthe only answer to recreating a MC from a WC, but it is not the panacea some would like to make us believe. [/quote]

[...]

a PLL is bound to introduce jitter, especially if it's "a simple one with low loop bandwidth". By definition , a PLL is constantly bouncing between lead and lag, which is a good definition of unstability.

I'm sorry, there were a few hidden assumptions there which I should have mentioned explicitly. For me, 'low loop bandwidth' means <<1Hz. As that is hard to do properly in an analog system (mostly due to capacitor imperfections) almost all such systems that I've worked with were digital PLLs, with either a microcontroller or a CPLD driving a DAC to the CV input of the VCXO. Again, almost all such systems have a 'hold' feature where they keep the control voltage constant when the phase detector output stays close enough to zero for a programmable length of time.

The less-than-infinite resolution of the DAC in a digital PLL makes the actual output frequency discontinuous, which may or may not be of consequence in terms of audio performance, but it's an unstability created by the very nature of the process. Jitter is traded against non-linearity and "sudden" bursts of drift (not that sudden if the loop is real slow). It is very likely to have less perceptible artefacts, but is it more euphonic? After all noise is apparently a a welcome addition in dithering...

 

[porkyc]

Going back to the original question!
In filmland and broadcast, you use AES 11 wherever possible, then WCK if you have to, anything with RS422 is going to want video syncs as well. All of this is generated by a house generator and distribution amps. Everything stars from those, and everything slaves to these. NONE of the equipment is the master.
AES "black" (as it is parodoxically called) is the best because it is balanced, robust, and (far more to the point) has a sync word in it, so not only is the gear going at the correct speed, but at the correct "NOW".

There is a thought that AES clocking should NOT be derived from an "audio" pair, but only from AES black. Can't say either way.
All I can tell you is that I've been involved with some big digital systems over the last 10 years, and once we started clocking them all with AES with the above rules, clocking problems were no longer an issue.

RME Audio has a good dissertation on digital clocking, but they are well into extracting clocks from MADI (mmm....!!)
PC

 

[jdbakker]

There is a thought that AES clocking should NOT be derived from an "audio" pair, but only from AES black. Can't say either way.

Data dependent jitter. There are a few AES papers on the subject.

JDB.

 

[porkyc]

Thank you. It's nice to get a definitive answer, not just hearsay!
The rules we follow in digital film and music consoles are only to use what I call "embedded" AES (ie in with audio data) if there is absolutely no other option. Generally, most of the things that have only WCK as a reference will also have video sync input as well to complete the timing.
Some bits of kit you can assign the AES black reference to an unused audio pair which works.