Topic: MADI interface : self-clocking or not?

Hello,
In my (old) time of audio schooling, I was always told that MADI interface was NOT self-clocking.
Now I see that mostly MADI products do not need a separate wordclock signal to be sync.
At first, I thought that AES improved the MADI protocole by embedding a strong sync frame...

But I read that on the MADI Wikipedia page :
"The basic data rate is 100 Mbit/s of data using 4B5B encoding to produce a 125 MHz physical baud rate. Unlike AES3, this clock is not synchronized to the audio sample rate, and the audio data payload is padded using JK sync symbols. Sync symbols may be inserted at any subframe boundary, and must occur at least once per frame. Though the standard disassociates the transmission clock from the audio sample rate, and thus requires a separate word clock connection to maintain synchronisation, some vendors do give the option of locking to parts of the transmission timing information for purposes of deriving a word clock."

This leads me to several interrogations :

Does the way RME manage the clock sync with MADI a proprietary one, only valid with RME MADI products? Or is MADI sync managing (w/out separate WC) a universal way of sync?

Does one of the following statements can be consider valid?

1) embedded MADI sync is just as strong as a good separate WC signal, with no measurable differences.
2) embedded MADI sync is not as good as a good separate WC signal, but do not provide any measurable issue in audio, whatever the sample rate.
3) embedded MADI sync is not as good as a separate good WC signal, but it's still usable. Nevertheless, using a separate WC signal has to be considered for certain high performances audio applications.

Best regards,
Laurent

Intel i7, Windows 10, RME UFX+, ADI-2 Pro FS R BE, ADI-2 FS, Ferrofish Pulsar16 MX

Re: MADI interface : self-clocking or not?

Hi Laurent,

please read this information on web about RME SteadyClock:
https://www.rme-audio.de/steadyclock-fs.html

This SOS article is also very informative:
https://www.soundonsound.com/people/rme-designs

Come back if you have remaining questions.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

3

Re: MADI interface : self-clocking or not?

Here's another one.

https://archiv.rme-audio.de/en/products/madi-center.php

Regards
Matthias Carstens
RME

Re: MADI interface : self-clocking or not?

Thank you guys for those links. I'll check it out.

Best,
Laurent

Intel i7, Windows 10, RME UFX+, ADI-2 Pro FS R BE, ADI-2 FS, Ferrofish Pulsar16 MX

Re: MADI interface : self-clocking or not?

Hello again,

I still struggle with the MADI clocking...

In the UFX+ user manual :
https://www.rme-audio.de/downloads/fface_ufxplus_e.pdf
page 118, chapter 40.8, there's an oscilloscope screenshot showing a yellow heavily jittery clock signal (from S/PDIF) and a blue clean refresh clock signal after applying SteadyClock-ing.
Should we understand that SteadyClock make a clean signal from a jittery clocked signal but, due to inner analysing/computing, this clean clock signal is a little bit delayed with the original clock signal?

Let's imagine this setup : I have an UFX+ linked with a distant Octamic XTC with MADI. There's also a (local) digital device connected directly to the UFX+ through ADAT for instance.
I use the UFX+ as the clock master. Local device clock is set to slave through ADAT, and the distant Octamic clock is set to slave through its MADI input.
Could I say that my local ADAT device and the Octamic are strictly sync'ed as if they would have been if they were both connected to an external common WordClock signal (or if MADI were a real self-clocking signal)?

In this kind of setup, should I rather put the Octamic XTC as the clock master, and put the UFX+ clock (and any digital devices connected to it) as a slave, through MADI?
If I connect an ADAT device to the ADAT input of the distant Octamic XTC, should I put this device as the master clock and make all other devices slaves (directly or relatively) to it?

Thanks in advance,

Regards,
Laurent

Intel i7, Windows 10, RME UFX+, ADI-2 Pro FS R BE, ADI-2 FS, Ferrofish Pulsar16 MX

Re: MADI interface : self-clocking or not?

Hello Laurent,

First - RME's implementation of clocking from Madi works very well, used it for many years on many devices.  Best in the business actually and we use a LOT of Madi devices.

Could I say that my local ADAT device and the Octamic are strictly sync'ed as if they would have been if they were both connected to an external common WordClock signal (or if MADI were a real self-clocking signal)?

I recognize clocking can be confusing until you master it but if I interpret your questioning correctly - all good questions incidentally if you're trying to understand - your issue is confusing how the clock must appear to and between devices.

Short version - accurate to a first order of approximation - clocking does not need to be exactly temporally synchronous between devices, but it must be at exactly the same rate between devices.

Long version -
Generally the rising edge of a wc signal is considered the start of an audio timing frame whether it's AES, adat, Madi, video blackburst, or whatever, so let's call that our zero time reference.  From that simple 48k sample clock (which started out as an I2S bus, high=left channel, low=right channel) the device being clocked uses a PLL to derive a 256x or 512x internal clock, called an mclk, that is the actual internal audio clock within the device.  The PLL constantly compares that inbound 48k slightly jittery word clock with it's own internal mclk (that's the definition of a PLL) and makes small adjustments to make sure the internal mclk is accurate to the inbound clock.  This mclk is used to drive the A/Ds, D/As, and other audio clocks (I'm leaving out FPGAs, this is a simplification).  The PLL is the basic topology block, RME's SteadyClock is an extremely good hardware and software implementation of the concept.

As soon as you feed a wc signal to a device you have introduced jitter, indeed sending signals across the circuit board induces jitter.  Can be very small jitter, can be huge jitter.  So already in every device there's not a correlation between the exact timing of the zero timing reference between devices, the inbound PLL must convert the wc signal into the mclk plus LRclk and that takes time.  Some devices may use the PLL to approximate the zero timing reference to match the inbound, some don't, but it doesn't matter.  As long as the clocks are moving at exactly the same rate the clocking will be fine between the devices.

Imagine a wc signal locally and at the end of a -really- long piece of fiber.  The clock master's internal LRclk and mclk are driving it's local conversion.  The conversion to fiber plus the long piece of fiber plus the conversion to copper wc into the device creates a delay between the zero ref of the clock master and the zero ref of the remotely driven device.  It does not matter - as long as the rate is exactly the same between devices the phase (not talking about polarity!) between the clocks does not matter.  The remote clock can be offset any amount in phase, plus the returning audio takes some time which creates further phase offsets, but as long as it's speed is accurate the clocking will work.  Zero time is not zero time anywhere except within a device (and even then there are delays... just saying).

So back to Madi.  Madi is not defined as a synchronous signal.  However SteadyClock can make a good reliable clock of inbound Madi and it does so quite well.  Every good quality device as a general rule will -technically- work most accurately on it's internal clock since it's not doing PLL adjustments from a low frequency inbound, and every device has varying degrees of accuracy when clocked externally.  Is there an audible difference?  Sure in theory - if a device does not have a fantastic PLL on the input then clocking externally will sound different than clocking internally.  With good quality devices you generally can't hear the difference.  There are many conspiracy theories around external/internal clocking so that's not the discussion, the take-away is you use the best clocking scheme for your application.  Fortunately for RME SteadyClock if the clocking between devices is reliable and reasonably low jitter it will sound the same no matter how it's clocked.  Not all devices operate as painlessly.

I hope this helps, the summation is - clocking delay doesn't matter.  Clocking speed does.

Hugh

7 (edited by ramses 2020-04-27 06:36:14)

Re: MADI interface : self-clocking or not?

I would like to mention operational aspects. If the clock master is the recording interface which is directly connected to the PC, then the sample rate of every device is automatically set to the value which is set in your DAW project.

Your setup is perfect, you do not require WC. UFX+ as master, all other devices clock slaves and get clock via ADAT and MADI.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

Re: MADI interface : self-clocking or not?

OK, I'm starting to understand the point (looks like I should read digital conversion theory books !)
Thanks Hugh and Ramses for this clarification, really much appreciated,
Laurent

Intel i7, Windows 10, RME UFX+, ADI-2 Pro FS R BE, ADI-2 FS, Ferrofish Pulsar16 MX

9 (edited by oortone 2023-08-17 09:55:43)

Re: MADI interface : self-clocking or not?

Hugh wrote:

So back to Madi.  Madi is not defined as a synchronous signal.  However SteadyClock can make a good reliable clock of inbound Madi and it does so quite well.  Every good quality device as a general rule will -technically- work most accurately on it's internal clock since it's not doing PLL adjustments from a low frequency inbound, and every device has varying degrees of accuracy when clocked externally. …

Hugh

Sorry for waking this up but after reading your excellent explanation Hugh, there’s one thing I still don’t get in the quoted passage.

If a device syncs to incoming madi (but not wordklock I gather) how come you mention ”internal clock” and ”not doing PLL” in that context? Still it will have to use (something similar to) PLL to generate a clock signal, right? Is there any conceptual difference between using madiframes or wordclock frames when syncronizing from an external incoming source?