SPDIF vs. Word clock question

[Magpel]

Hi, please help me think this through...

I am currently using a Delta 1010 and would like to either replace it with a bank of better converters/interface or, quite possibly, augment it with more of a gold channel ADC and stick with the 1010s DACs until a future upgrade.

Looking, for example, at the Mytek Stereo96 ADC. I would get two class converters, and I've also been led to believe over the years that there may be advantages associated with clocking the Delta 1010 externally The Black Lion critique of the 1010, for example focuses largely on doubts about its clock.

So..in my none-too-slutty rig, the Delta 1010 has word clock in and SPDIF in. To get the audio from the Mytek into the DAW, I would need to SPDIF it through the Delta 1010 first. When the Delta 1010 receives SPDIF, it defaults to the clock of the incoming signal (excuse my clumsy language...).

In that scenario, am I still getting the full advantage of the Mytek's superior clock, i.e., is there anything inherently shaky in clocking through a SPDIF connection?

Second, if there is something inherently shaky in SPDIF, could I still use the Clock out on the Mytek into the Delta's Clock in, or does the SPDIF connection supersede all of that?

Thanks for bearing with me...

[Francis Vaughan]

is there anything inherently shaky in clocking through a SPDIF connection?

Yes. S/PDIF is a horrendously poorly designed interface. This is because it combines the clock and audio coding onto the same signal. The receiver is supposed to recover the clock from this signal as well as extract the audio data. This turns out to be a non-trivial task, and one that almost always leaves the recovered clock contaminated with signal correlated jitter artefacts. So any clock you transmit over an S/PDIF connection that is also carrying audio signals will probably be worse than any internal clock.

You can reasonably (but not ideally) send a clock over an S/PDIF interface if the interface does not carry any audio signal, but even then the poor bandwidth of the interface does not lend itself to particularly accurate clock reticulation.

Clocks are hard. Really hard. Even proper word clock distribution systems are far from ideal, but S/PDIF is particularly flawed, and should have no role in any transmission that involves clock recovery.

[Magpel]

Originally Posted by Francis Vaughan

Yes. S/PDIF is a horrendously poorly designed interface. This is because it combines the clock and audio coding onto the same signal. The receiver is supposed to recover the clock from this signal as well as extract the audio data. This turns out to be a non-trivial task, and one that almost always leaves the recovered clock contaminated with signal correlated jitter artefacts. So any clock you transmit over an S/PDIF connection that is also carrying audio signals will be probably worse than any internal clock.

You can reasonably (but not ideally) send a clock over an S/PDIF interface if the interface does not carry any audio signal, but even then the poor bandwidth of the interface does not lend itself to particularly accurate clock reticulation.

Thanks, Francis. I am wondering then if it is somehow possible to use Wordclock out/in from Mytek to Delta, and use S/PDIF just for the audio, as you suggest. I think you can't, as the Delta control panel automatically takes clock for S/PDIF id the S/PDIF input is engaged.

[Francis Vaughan]

Originally Posted by Magpel

Thanks, Francis. I am wondering then if it is somehow possible to use Wordclock out/in from Mytek to Delta, and use S/PDIF just for the audio, as you suggest. I think you can't, as the Delta control panel automatically takes clock for S/PDIF id the S/PDIF input is engaged.

Does the 1010 not have a Master Clock control panel? You can set the Word Clock as the clock. here. (Page 23 of manual). This should subsume the use of the S/PDIF signal as clock. This assumes that all the connected devices share the master clock source (which is of course the whole point.) This must include the device from which you are receiving the S/PDIF signal as well.

[Magpel]

Originally Posted by Francis Vaughan

Does the 1010 not have a Master Clock control panel? You can set the Word Clock as the clock. here. (Page 23 of manual). This should subsume the use of the S/PDIF signal as clock. This assumes that all the connected devices share the master clock source (which is of course the whole point.) This must include the device from which you are receiving the S/PDIF signal as well.

Right, and on page 8 it says that the sync source can be set to External Clock or to S/PDIF to use the S/PDIF input. I had thought clock HAD to be set to S/PDIF to use that input.

So that is somewhat good news, I guess, though your warnings are still heeded.

[dashamu]

You can reasonably (but not ideally) send a clock over an S/PDIF interface if the interface does not carry any audio signal, but even then the poor bandwidth of the interface does not lend itself to particularly accurate clock reticulation.

Hope this isn't too much of a hijack, but I posed a similar question a few weeks back regarding connecting a Rosetta 200 to a MOTU 2408. The consensus seemed to be that since I was only sending 2 channels of audio to the 2408 that the SPDIF connection would be fine for audio AD and clocking. I'm assuming that the DA stage would be less of a problem because the SPDIF audio out isn't carrying any clock info?

I was wondering if a word clock connection would be better but was advised to try the SPDIF first and if I noticed any problems ( I haven't), connect the word clock. I've already noticed a subtle but important improvement using the SPDIF connection. What would I be listening for if I connect to word clock. Is it audible? Measurable? Worth the price of a cable?

Thanks

[Kiwiburger]

I could be wildly mistaken, but this is my laymans understanding that influences what I do ...

From what I can tell, the most stable clock for any A/D converter will be it's own internal clock. It doesn't have any distance to travel, and unless there is serious AC contamination problems, it should have very little jitter.

From what I understand - trying to get an A/D converter to sync up to an external clock is asking for problems - no matter how good and pure that external clock source is. So as far as i'm concerned, I would always use the internal clock of a converter. If I needed to sync multiple converters, I would try to keep them all the same model, and use their proprietory syncing format as first choice. (I use API A2D, and link mine with the DB9 serial port cables).

AFAIK - once the signal leaves the A/D, it doesn't matter if the actual timing of the data stream varies slightly. It's just data, which either arrives to be processed or it doesn't.

On playback, the reverse situation applies. I don't believe there is any better clock than the D/A converters own clock (if it has one). I use a Benchmark DAC-1, and it doesn't really matter if there is a little jitter in the incoming data. Basically the DAC-1 has it's own clock, and the incoming data is re-clocked to this.

I have no doubt that in the past there have been some dodgy a/d and d/a converters that have sounded bad due to jitter. And I have no doubt that they sounded better when an external clock was used. But I would like to think that basically those days are over, and the need for external clocks has virtually disappeared.

Maybe if you have a mish mash of assorted converters that you need to sync up, then maybe an external clock is a solution. But I would like to think that the best solution is to choose good converters with good internal clocks, and let them do their own thing.

[Quantumphysics]

great thread - I'm in a similar situation - I have (2) 1010's and an ADi-2 (ADI has no word clock) - I've been using the ADI-2 as the master - so what's the final conclusion?
when recording use the 1010's clock?
and when mixing using the ADI's clock?

[Francis Vaughan]

There is probably much wisdom in the idea that the internal clock is usually the best one. Unfortunately there a lot of places where this eventually becomes troublesome. And it can become troublesome in really unfortunate ways.

So, the problem we have is that, say we have two separate ADCs. Each used on its own will use its internal clock, and generally be pretty happy. The reality is that a well designed crystal oscillator can have vanishingly small jitter and so long as the clock distribution within the ADC is done properly it will perform as well as anything you can imagine. (This includes exotica such as atomic clocks.)

But, crystals are not perfect for frequency stability. Crystals age, have thermal drift and have tolerances in manufacture. It is very unlikely that out two ADCs will have exactly the same frequency. This will start to cause problems. A typical crystal oscillator might have 20ppm, a very good one 5ppm. So on average you might expect a difference of say half that between two ADCs. Lets be very generous as say that the disparity is 1ppm. That would be lucky. Two timepieces that were this close would read to within a second of one another over 11 days. But your two sample clocks in the ADCs, sampling at the pedestrian rate of 44.1kHz get out of sync by one sample in 23 seconds. Use a more modern sample rate, say 96kHz, and you get one sample out every 10 seconds. More realistic tolerances and higher sample rates mean you get a sample out every few seconds.

The problem you have is: what do you do with that sample? You can't just drop it. That will sound horrendous. You get a "tick" every time you do. You could just let one drop behind the other, but this only works if you know that the clock you use as master is always the slowest - and needs buffers for all the faster clocked sources. It isn't going to be satisfactory.

Some digital audio systems will use an asynchronous sample rate converter. And indeed there are hidden async sample rate converters lying in wait for the unwary inside Windows. One trouble with async sample rate converters is that they don't do a good job if the input and output rates are very close, they are designed to convert, not to correct. You see plenty of ASRCs used for rate conversion, particularly if 44.1 is involved, as it is not a simple multiple of any other rate.

So the obvious answer is a system wide synchronisation. Someone sets the rate and everyone else follows. But you are now left with the need to synchronise your local clock in some way. The need comes from a number of factors. Internally ADCs and DACs typically run much faster clocks than the word clock. Any oversampling device (which apart from a few lunatics) is every ADC and DAC made, and especially Delta Sigma converters, need clocks that run at significant multiples of the word clock.

Next there is the problem of clock jitter. The need for accurate time on the edges of the sample clock is extraordinary. You can see roughly the accuracy needed if you do even some very simple order of magnitude calculations. Take a 96kHz sample clock at a simple 16 bits. The time error that corresponds to the LSB is 0.3nS. Any clock jitter of this order has already wiped out anything below 16 bits. So with a 24 bit converter at 192kHz, you are asking for clock accuracy of picosecond accuracy. To put this in context, light travels 0.3mm in one pico second. (There is a clue here as to why full 24 bit resolution isn't actually possible. But to get full benefit from you converters you need them to see a clock that is seeing jitter in the picosecond range. This is a very difficult technical challenge. It is even harder if you are required to sync you clock from an external source.

The technical answer to syncing a clock is a phase locked loop. You have a local clock oscillator that can have its frequency controlled (pulled) by a controller. The system watches the phase of the incoming clock and the local clock, and applies a change in the frequency control if the local clock in order to get it in sync. This change in frequency control is damped so that it doesn't move too fast. Other wise any jitter (also known as phase noise) is reproduced on the local clock. This dampening is the manner in which jitter on the external clock is attenuated. It can never be perfect, that would mean that the local clock would take infinite time to reach sync. So a compromise is reached. With care it can be pretty good. But care usually translates to money - so you will get what you pay for.

In the domestic arena S/PDIF became common as a digital audio interconnect. Sony/Phillips Digital InterFace. From the designers of the CD, and intended as a medium to send a CD sourced signal. It is appallingly designed. Because it is a single signal it encodes both the data and the clock on the same signal. Essentially the clock edges used for the data signalling are supposed to be used to receiver the sample rate clock. This isn't a big deal if you are building a serial data transmitter, but is a very big deal if you are building a clock transmission. The presence of signal data contaminates the clock recovery process with signal correlated artefacts. It is very difficult to attenuate these artefacts enough, and pretty much impossible to get them to the picosecond level needed for full 24 bit resolution. Even 16 bit resolution is a tough technical challenge. Because they are signal correlated they are a specially important to remove - they aren't just noise, but translate to audible artefacts, often involving peculiarly nasty dissonant components.

If a S/PDIF signal has no audio signal data on it, it isn't so bad. But it still isn't ideal.
Anything at all that introduces noise into the clock recovery process is bad. Word clock reticulation systems are at least designed with the right intent, even if they still suffer from technical limitations. The clocks must be treated as RF signals. They need all the care and feeding of a critical signal at radio frequencies. So, they must be reticulated in a proper transmission line, and line termination and impeadances must be maintained. But even the common techniques used are really to be found wanting. Common tricks involving T-pieces on a work clock line will degrade the clock. The T-piece will introduce enough of an impedance mismatch that a significant reflection occurs, which will end up adding unwanted energy to the the clock signal - energy that will be very difficult to attenuate sufficiently to avoid contaminating the sample clock.

AES/EBU is really no better than S/PDIF, the protocol is (bar trivial details) the same, and it suffers from the same signal correlated jitter issues. In fact, due to its use of an XLR connector it has impossible to cure problems with RF transmission. Just how it came into being is something of a mystery. It certainly didn't involve any engineers who knew anything about RF.

Everywhere you look you see vendors offering proprietary clock recovery systems for their gear, all claiming <insert marketing adjective> low jitter. Lots of cute marketdroid inspired names for their systems. Most only really claim about a nano second. This is arguably still not good enough. Cute marketing names and hand-waving vacuous claims are not yet enough.

[TommyFullzy]

Sorry to resurrect...

I have a Lucid AD9624, a Focusrite ISA w/digital card and a 002.

Would it be best to

a) clock the 002 to the Lucid via spdif and connect the ISA via analogue to the Lucid (this is what I would have chosen) or,

b) sell the 002 and get a 003 rack (I don't need the control surface anyway and could use the extra space), then sync the lucid and the 003 via BNC from the ISA wordclock out (while still outputting via analogue). The Lucid does not have wordclock out (unfortunately). This way the clocking is via BNC (which you state to be the better option) but the Lucid's conversion is not clocking from its internal clock (which you also state to be the better option).

I have lucid conversion on my 002 outputs anyway, but I would like my other i/o sounding the best they can.

Thanks,

Tom.

[BadJones]

Originally Posted by TommyFullzy

Sorry to resurrect...

I have a Lucid AD9624, a Focusrite ISA w/digital card and a 002.

Would it be best to

a) clock the 002 to the Lucid via spdif and connect the ISA via analogue to the Lucid (this is what I would have chosen) or,

b) sell the 002 and get a 003 rack (I don't need the control surface anyway and could use the extra space), then sync the lucid and the 003 via BNC from the ISA wordclock out (while still outputting via analogue). The Lucid does not have wordclock out (unfortunately). This way the clocking is via BNC (which you state to be the better option) but the Lucid's conversion is not clocking from its internal clock (which you also state to be the better option).

I have lucid conversion on my 002 outputs anyway, but I would like my other i/o sounding the best they can.

Thanks,

Tom.

Very good question, another maybe is it better to clock the 002 via adat pipe vs spdif?

Sorry I can't help you but am curious to know.

[TommyFullzy]

The lightpipe connection is using spdif, the lucid is a 2 channel converter and doesn't support ADAT.

If you are referring to the RCA/coaxial spdif connection, I presume there is no point in using that since in theory the optical connection should be the same (since it is also using spdif) and the optical cable run can be longer without degradation?

[BadJones]

Originally Posted by TommyFullzy

The lightpipe connection is using spdif, the lucid is a 2 channel converter and doesn't support ADAT.

If you are referring to the RCA/coaxial spdif connection, I presume there is no point in using that since in theory the optical connection should be the same (since it is also using spdif) and the optical cable run can be longer without degradation?

I'm not so sure, the lightpipe is using light signals where as the rca coax connection is using electrical impulses.

In general, not pertaining to your particular setup; Is it better to use the coax/spdif or the adat/lightpipe to clock the digi 002?

You would think lightpipe because there is no electrical interference, but the opto receiver would have to be pretty accurate in the digi 002?

I'm thinking of just getting a digi003 with the bnc connector, but if there is no difference vs digi002 clocked thru it's spdif or adat it would be just a waste of money.

[prado escondido]

So where has the erudite Francis Vaughn left us?

Among imperfect solutions, which is best? Or does it all depend? And on what?

Is it better to T-connect Work Clock or daisy chain? And does the answer depend on the number of linked units and or the travel distance?

Please, don't leave me here!

What about ADAT and Word Clock ... can they run compatibly as clock conduits?

Running Cubase 5 (if that makes any difference) and 4 devices I am interested in syncing: RME Multiface II with word clock in and out and ADAT; Mackie Onyx 800R with word clock in, termination switch and ADAT; a Roland XV-5080 with word clock in; and a Motu Timepiece AV with a 9-pin serial ADAT out and word clock out ... where do I start?

If I understand correctly, since the Motu Timepiece AV has only work clock out, then it must be the master clock. Correct?

This explained a lot, but not really how to go forward with sorting out what you need do with the equipment you have.

Digital Clocking Explained

Thanks for any help.

Prado

[Francis Vaughan]

Originally Posted by prado escondido

So where has the erudite Francis Vaughn left us?

In his tomb at R'Lyah ... dreams ...

Among imperfect solutions, which is best? Or does it all depend?

Pretty much yes - it depends.

And on what? Is it better to T-connect Work Clock or daisy chain? And does the answer depend on the number of linked units and or the travel distance?

From a simple RF point of view T-Pieces are not good. Even though the ends are terminated correctly, the T-piece can never present a correct impedance. A T connected directly to the BNC connector on the back of the clock master is as good as you can get (never - ever - put a cable between a T and the point it is distributing from), and even this presents an easily measureable impedance glitch. How bad this turns out to be will depend on a host of other second order issues.

But daisy chaining assumes that the daisy chain repeater is not making a mess of things either. However it is possible to do a proper job of a repeater, whilst is isn't possible to do a proper job with a T. So, first cut is to daisy chain, unless you know the repeater is poor. This might be done as a first approximation of putting the better quality gear early in the chain - but that makes some assumptions too.

What about ADAT and Word Clock ... can they run compatibly as clock conduits?

If you mean "can I reticulate a clock over ADAT Optical Interconnect?" clearly yes. You can't find out the actual format of the interconnect without a license, but it isn't exactly hard to guess at the basics. The important thing is that they will (at worst) be recovering the clock from the frame clock used for the packects that are sent over the link. This won't suffer from the same problems as S/PDIF does. In particular there isn't a mechanism for signal correlated aretefacts to get onto the recovered clock. On the other hand, since it uses a plastic optical link the bandwidth is sorely limited (the plastic medium causes the pulse edges to spread out) and thus there is less accuracy in recovereing clock edges (and thus more noise) than with coaxial links. This could lead to power supply and other extranious noise influencing the recovered clock a bit more easily. But in general it probably doesn't matter all that much. Vastly less of an issue than the problems that S/PDIF brings with it. That is so long as you can actually construct a system that such reticulation works for. Which is much less likely.

RME Multiface II with word clock in and out and ADAT; Mackie Onyx 800R with word clock in, termination switch and ADAT; a Roland XV-5080 with word clock in; and a Motu Timepiece AV with a 9-pin serial ADAT out and word clock out ... where do I start?

Since the Motu (since that is the whole point of it) can only act as a clock master you only have one choice for the head of the chain.

After that it is a matter of clock reticulation. Whilst, in principle it is possible to reticulate clock over ADAT, the gear you have doesn't really allow you to do it. Mostly because it is ADAT out only (800R, XV-5080) or it only syncs clock on Word-Clock anyway (RME).

So you are left with the question of how best to reticulate word clock over coax. With what you have, the RME seems to have taken the most care with its output driver circuit, so I would start with this:

MOTU --> (in + termination )RME(out) --> (T-piece)XV-5830 --> (Termination on)800R

The reason for putting the 800R last is that it provides internal termination, and I consider that a better answer than a T-piece with a terminator. There isn't the same glitch in the line.

Like I wrote above, I don't like t-pieces, a TDR (time domain reflectometer) can trivially show the presence of them in the line, but short of a dedicated word clock distribution amplifier there isn't much choice here.

[prado escondido]

Originally Posted by Francis Vaughan

MOTU --> (in + termination )RME(out)

Francis ... outstanding! Thanks so much for the help and particularly for not being offended by my prodding to resurrect this dormant thread.

I must admit, some of what you say goes right over my head ... but your suggestions of a practical way forward is extremely clear and helpful.

I'm only unclear on one specific, "(in + termination) RME ...", or more discretely "+ termination." Is this a function particular to my RME, or just a general concept I'm otherwise ignorant of?

One other 'theoretical' question ... probably fully displaying the depth of my ignorance, if you don't mind. Now that I've though more about it, it seems that the reason the XV-5080 has Word Clock in is so that the Roland R-Buss digital outs can be used. If I'm only recording the analog outs to the RME or Mackie 800R, does the XV-5080 really need to be in the clocking chain? My JD-990 certainly can't be! If I don't need to I can avoid the 'T' connectors all together.

Finally, does the sequencer, Cubase in my case, also some how need to connect to the MOTU clocking?

If you tire of this, please feel free to ignore me henceforth ... you've already helped me immensely.

Best regards.

Prado
Escondido, California

[Francis Vaughan]

I'm only unclear on one specific, "(in + termination) RME ...", or more discretely "+ termination." Is this a function particular to my RME, or just a general concept I'm otherwise ignorant of?

What I was trying to convey is that the input should be terminated. When you have both an in and out we assume (note: assume) that the signal is proerly repeated and it isn't just the equivalent of a t-piece. So you need to terminate the coax line here.

You have two separate coax runs in this configuration. MOTU --> RME and RME --> the rest. The end of each run must be terminated.

If I'm only recording the analog outs to the RME or Mackie 800R, does the XV-5080 really need to be in the clocking chain?

Indeed, no it doesn't.

If I don't need to I can avoid the 'T' connectors all together.

Yup.

Finally, does the sequencer, Cubase in my case, also some how need to connect to the MOTU clocking?

I assumed that this is how you were linking MIDI control into the system. What I wasn't clear on is what you are using the MOTU Timepiece for. Clearly you are syncing disparate stuff together, which is the MOTU's job. So if the sequencing is over MIDI you may want to hold that together with MIDI time. The MOTU Timepiece however is a bit of overkill if that is all that is happening. I rather assumed there was a film or video element to the work that demanded the MOTU unit.

[nkf]

Originally Posted by Francis Vaughan

or it only syncs clock on Word-Clock anyway (RME).

Every RME device I have (over a dozen) can be synced from its digital inputs, no matter if it is ADAT, S/PDIF or AES/EBU. Using a RME device as a re-clocker is perfectly possible.
I agree T-pieces should be avoided but I would recommend word clock distribution amps for providing word clock in a star configuration (one source providing multiple inputs with word clock). From my experience I would use the (very good!) listening D/A (chain) as the clock source if possible.

[Francis Vaughan]

Originally Posted by nkf

Every RME device I have (over a dozen) can be synced from its digital inputs, no matter if it is ADAT, S/PDIF or AES/EBU.

Useful to know. All I had to go on was the rather interestingly written manual that didn't really cover the ground. I was surprised that it didn't indicate how to sync, but assumed that since there was no mention of setting it up to do so that it would not. In particular, setting it up to sync from a digital input that it is otherwise ignoring. Having it sync to an input that it is currently sucking data into is easy, but here we only want to sync to the clock in the data stream, and ignore the rest.

I agree T-pieces should be avoided but I would recommend word clock distribution amps for providing word clock in a star configuration (one source providing multiple inputs with word clock).

Yup.

From my experience I would use the (very good!) listening D/A (chain) as the clock source if possible.

I would be careful here. If you have a particular really good D/A that has a good clock, that will be great. But sadly there is not a great deal to suggest that this is trait that is common to all D/As. In general this comes in under the heading of "it depends".

[prado escondido]

Francis ...

I bought the MOTU .. at a used gear 'blow out' for $35.00 ... to use as a midi patch bay. It has 8 pairs of midi i/o and completely flexible routing from software or hardware.

I must be a bit thick ... and admittedly ignorant about this topic ... because I'm still not getting it.

When you say

MOTU --> (in + termination )RME(out) --> (T-piece)XV-5830 --> (Termination on)800R

are you saying that in 'daisy chaining' Word Clock, each separate run from a WC out to a WC in must be terminated for as many times as their are separate coax cables ... but the 'T-pieces' don't count? Which is why there is no mention of termination by the XV-5080?

And are you also saying that termination means something more than just hooking up a device in the middle of the chain ... the RME in my case ... to the untis WC in and WC out? Or are you just describing it as the technical fact ... for lack of a better phrase ... when any WC out signal enters the WC in of the next device?

I just assumed by going WC in and the WC out, from the RME in my chain, that would be all I had to do. Now I've got dig in my manual ... if I understand you ... and see how to set the termination.

Prado

[prado escondido]

I'm also now wondering if I'm way over complicating things for myself?

Really, I have a relatively simple setup. As far as I can see I only need to sync the RME Multiface with the Mackie 800R via a single WC run.

Part of my thought about using the MOTU as master clock was that since it functions as my midi patch bay it would also 'tighten' the over all timing of my midi sequencing, so, for example, were I recording several analog outs from midi synths simultaneously the sounds would be better controlled in the analog realm. But the more I think about it, the more I'm thinking that that is not the case.

Presumably what ever timing 'tightening' ... if any ... takes place with midi messages is already occurring within the MOTU or between Cubase and the MOTU.

The digital syncing is only strengthening the weakest or 'jitteriest' link in my AD conversion.

So, is there actually any reason/ benefit to including the MOTU in the WC chain in my simple setup?

Prado

[Francis Vaughan]

Originally Posted by prado escondido

I'm also now wondering if I'm way over complicating things for myself?

So, is there actually any reason/ benefit to including the MOTU in the WC chain in my simple setup?

You've got it. No reason at all.

[Francis Vaughan]

Originally Posted by prado escondido

are you saying that in 'daisy chaining' Word Clock, each separate run from a WC out to a WC in must be terminated for as many times as their are separate coax cables ... but the 'T-pieces' don't count? Which is why there is no mention of termination by the XV-5080?

That is not a bad way of thinking about it. So yes.

And are you also saying that termination means something more than just hooking up a device in the middle of the chain ... the RME in my case ... to the untis WC in and WC out? Or are you just describing it as the technical fact ... for lack of a better phrase ... when any WC out signal enters the WC in of the next device?

Termination has a specific technical meaning. The word clock signal contains energy right into the radio frequencies. This is because it has a very well defined edge to the shape of the signal. This is why it must be sent over a medium that is capable of working properly at RF. At these frequencies the electrical energy starts to behave like a wave, and the precise nature of the conditions it finds itself in matter a great deal. When the clock travels down the coax it is travelling in a transmission line, and so long as the impedance of the line in unchanged the energy continues to travel. If there is a change in impedance, some amount of energy will reflect from the point of the change. An you potentially end up with multiple reflections of the energy travelling up and down the coax. This can easily upset the reciever, enough that it can mis-time the clock edge's arrival time - and hence lead to problems. So you need to ensure that the energy never reflects. n particular you need to ensure that when it reaches the end of the coax that it is absorbed. To do this you need a resistor that has the same impedance as the charateristic impedance as the coax. The resistor absorbs the clock pulse's energy (turning it into heat) and nothing reflects back up the coax. So when you terminate the run you either physically attach a terminating resistor (i.e with a t-piece) or use an internal terminator inside the last piece of equipment. The termination switch simply places the termination resistor across the input.

Now, just to complicate matters, the use of proper termination results in a halving of the received signal level. Some equipment combinations may have trouble because of this. Not properly terminating won't usually stop the word clock from working, just increase the possibility of jitter in the sample clocks, but if the transmitter is weak, and the receiver is insensitive, you can actually have a situation where the connection only works with no termination. Not good. One hopes this is rare now.

[prado escondido]

Francis ... you're a 'master lecturer.'

Thank you, I've learned so much ... even if in the end for now I won't be putting it in practice!

But the day will probably come when I'm getting another piece of gear that will require syncing. At which point I'll know how to proceed with the MOTU WC out ... or whether I need a 'multi' WC out time piece.

This has been great. You're welcome to return to your slumbers as far as I'm concerned.

Prado