MADI Confusion

[Doublehelix]

There is another thread running where member SnipSnip is discussing his converter needs, and the subject of MADI keeps popping up, usually with cooperation from Redleicester. I did not want to hijack his thread too much, so thought I would start a new onw.

In some of their conversations, It appears that SS is planning on using a set of Lynx Aurora converters (which come standard with AES/EBU digital outputs) into an RME MADI card.

I am a bit confused about MADI. Obviously, I have heard of it and know that it is a high-end, high-channel-count format. What I am missing is how you are converting from AES/EBU to MADI, and how the two formats might be related.

I am using the Lynx AES-16 card with my Aurora-16, and if I want to up the channel count, I will need to get another AES-16 card along with another converter. I was just wondering if maybe MADI was an option, and if so, how?

Thanks!

[snipsnip]

Hi DH,

As i understand it, the lynx does not have madi... only the SSL.

Hence me considering SLL, as it would cost me too much to expand my lynx channel count to 24 via aes cards.

[Aural Reject]

DH - have a 'chat' with Max! and 0VU in addition to RL....

Their usage is (IMO) considerably different, however, as they use it on location for carrying large channel counts down a single cable...which simplifies matters somewhat when you're not having to carry a squillion miles of copper multicore.

It has it's complications though - I'm not too convinced in a 32 channel studio environment whether you'd see a huge benefit. You'd need to add a AES to MADI converter (something like the ADI6432) and then a MADI interface (such as the HDSPe MADI) as well....I'm sure the big boys will leap in and correct me, though

[Hugh Robjohns]

MADI -- multichannel digital audio interface.

It is closely related to the AES family which includes AES3, AES3-id, coaxial S/PDIF and optical S/PDIF (TosLink).

They all use near-identical data structures and the same data rates. Only the physical interfacing varies (and not by a lot).

MADI was originally designed to convey 28 standard AES signals (each being stereo, of course) over a single coax cable. That gives a total of 56 individual channels, and it was intended to be used to hook up a digital multitrack system to a mixing console with just two cables. These days it is used for that a lot, but also for FOH to stage multis and splits for recording and broadcast of live events. It is also often carried on fibres rather than coax.

The standard was subsequently extended to accommodate 64 channels and is now called MADI-X. Most systems can be switched to work with the older 56 channel frames if required.

Some kind of converter is needed to translate between the AES format (or any other digital interface) and MADI. RME are the masters at building these kinds of interface, but there are others around, including SSL, Euphonix and others.

In the case of AES-MADI interfaces, there isn't that much internal jiggery-pokery required since the AES frames can be slotted directly and easily into the MADI structure, and vice versa. Other types of interface (ADAT, TDIF etc) will need to be transformed to an AES style format before combining to the MADI structure.

Obviously, all 56 or 64 channels within a MADI stream have to be sample rate synchronous. Some MADI interfaces incorporate sample rate converters to deal with unsyhcronised sources. Most do not.

If you have to move a large number of discrete channels a long way, MADI is undoubtedly a good way to do it (although there are now others such as M-DAC). But if you are only dealing with 20 or 30 channels, the expense of the interfaces and converters may well not justify it. AES3 or AES3-id will travel a heck of a long way very reliably, and the cost of the long cables will usually be less than the MADI converters!

Hope that helps

Hugh

[Aural Reject]

Hi DH,

As i understand it, the lynx does not have madi... only the SSL.

Yep - it's a shame there's no option for MADI on the Aurora.

There are other options that output MADI though - the RME ADI-8 QS is another.

[Aural Reject]

Stuff.

Hugh

I think you've written that before

[redleicester]

Clever Technobabble Stuff.

Edited for accuracy

DH - the other thread is discussing the option of using MADI and the SSL box OR the Lynx systems - not connecting the two together.

[Steve Hill]

These days it is sued for that a lot

Seems a little harsh, even to this retired lawyer

[Doublehelix]

Thanks everyone for all of the information re: AES/EBU and MADI. I *thought* that they were not directly compatible, but it is interesting to find out that they are actually pretty close format-wise.

At this point, I am going to stick with AES/EBU.

[Hugh Robjohns]

oops! Trust you to spot that typo!

hugh

[Tommy Tucker]

From the original post I'm guessing you're not after a lecture on the fundamental theory of digital formats? MADI is a great (and cheap) way of passing many audio lines over long distances. Hardly any cabling involved and setup is a breeze. It will only be of any real benefit to you if any of the devices in your system directly supports MADI (Lynx not being one of them). I'd say in your case, using multiple AES16's is the clear choice?

Otherwise, plenty of good (and digestible) info from:

http://www.rme-audio.de/en_products_madi_center.php?page=content/products/en_products_madi_center

[ken long]

Obviously, all 56 or 64 channels within a MADI stream have to be sample rate synchronous. Some MADI interfaces incorporate sample rate converters to deal with unsyhcronised sources. Most do not.
Hugh

emphasis mine

Hi Hugh,

From what I understand, MADI protocol is self-clocking but does this mean you could technically take multiple digital streams from different clock sources at once into your (slaved) interface?

If so, could you give an example of one such device (MADI Interface)?

Thanks.

[Hugh Robjohns]

From what I understand, MADI protocol is self-clocking but does this mean you could technically take multiple digital streams from different clock sources at once into your (slaved) interface?

It is self clocking, as you say. Basically it is an AES3 stream, but instead of just sending alternate left and right samples it sends 64 channels one after the other instead.

Consequently, each of those source channels must be synchronised to the same clock.

Where a MADI interface accepts multiple AES3 or ADAT inputs, those sources either need to be clocked synchronously, or the MADI interface will need asynchronoous sample rate converters on its inputs to accommodate free-running sources.

I came across the latter in the early days of MADI with some BBC protoype interfaces, but I'm not au fait with the features of all current MADI interfaces and don't know of any specific models that can accommodate asynchronous inputs.

Does that help?

hugh

[ken long]

Does that help?

Indeed. Thanks for taking the time.

Where a MADI interface accepts multiple AES3 or ADAT inputs, those sources either need to be clocked synchronously, or the MADI interface will need asynchronoous sample rate converters on its inputs to accommodate free-running sources.

I came across the latter in the early days of MADI with some BBC protoype interfaces, but I'm not au fait with the features of all current MADI interfaces and don't know of any specific models that can accommodate asynchronous inputs.

I was looking at this:

http://www.avid.com/US/products/HD-MADI

particularly,:

Forget having to match sample rates, thanks to built-in SRC on all I/O channels

but I'm not sure that accomodates multiple clock sources.

[Hugh Robjohns]

It looks to me that the box is essentially a MADI to HD card interface, and the reference to the SRC means that you can connect a MADI signal from a source which is not synchronised to the PTHD system, and without having to slave the PTHD clock to the MADI source.

hugh

[ken long]

cheers Hugh.

No way to sync to multiple clocks then. Ill add that to the Dear Santa thread then...

[redleicester]

cheers Hugh.

No way to sync to multiple clocks then. Ill add that to the Dear Santa thread then...

RME ADI-192DD

[ken long]

Thank you, sir!

[redleicester]

Glad to help.