In This Section
- Open Control Architecture - Part 3: Protocol for TCP/IP Networks; AES70-3-xxxx DRAFT proposed for comment
- Open Control Architecture - Part 2: Class structure; AES70-2-xxxx DRAFT proposed for comment
- Open Control Architecture - Part 1: Framework; AES70-1-xxxx DRAFT proposed for comment
- Audio-over-IP network interoperability; AES67 revision published
Comments on REAFFIRMATION of AES-10id-2005
Comments to date on REAFFIRMATION of AES-10id-2005, AES information document for digital audio engineering - Engineering guidelines for the multichannel audio digital interface, AES10 (MADI) ,
published 2011-01-04 for comment.
Comment received from J. Simpson, 2011-01-06
Section 9.4 of this document seems out dated. Automatic equalisation is not of doubtful value, as it can dramatically increase the potential cable length possible with MADI (our devices comfortably achieve over 300 meters with RG59 cable), as well as providing better fault tolerance and error margin for shorter cables. It is correct in the assertion that many equalisation devices are designed for specific video standards, but there are also many devices that can operate over a wide range of data rates, for example devices from National Semi, Maxim IC, Genum. The assertion that these devices work simply by measuring the received signal amplitude is also incorrect; this may be true for analogue video equalisers, but devices designed for digital signals are more sophisticated. Lastly, the assertion that loss of signal detection is very difficult with such devices is also incorrect, as several that I have looked at feature an output pin to provide this precise function.
I would propose replacing this whole section with a simple statement along the lines of "Cable equalisation may be used in the MADI receiver circuit, but is not a requirement of the standard".
Jeff Simpson: Design Engineer, Allen & Heath
Response from J. Grant
Dear Mr Simpson,
Thank you for your comment and I apologise for the delay in addressing it.
You are of course correct in saying that the paragraph is outdated - if not why would revisions be necessary? The statements made were based on the author's experience at the time, from several years previous up to 2004.
We have consulted with those who have experience on this matter and are assured that what you say is correct, but with a rider that UNTERMINATED inputs can give rise to instability, causing unworkable crosstalk in chips with multiple inputs.
Your suggested wording would be entirely acceptable in a standard, but the purpose of this document is to explain the details of the standard and bring those caveats borne of experience to the notice of new users - especially as the gentlemen who first wrote the standard leave the field to a new generation.
It seems logical to combine 9.4 with what should have been 9.5 but was always a second 9.4 for some long-overlooked editorial error.
We therefore propose to replace the two subclauses currently numbered 9.4 with the following single subclause:
9.4 Equalisation and Reclocking
Equalisation and reclocking are outside the scope of the AES10 standard.
Equalisation, including automatic equalisation applied by a receiver chip, can enhance the performance of the standard with respect to cable length and/or allow lower-cost cable to be used. However, some legacy integrated circuits may have a tendency to instability without an input signal, or when left unterminated. This has been known to cause difficulty due to crosstalk in multiple-input chips.
Reclocking is now regarded as normal and rarely causes problems, as available integrated circuits are designed to lock over a much broader spectrum including MADI rates.
Please let me know by 27th April if this reply is not acceptable to you. You may also ask us to consider your comments again for the next revision of the document. You may also appeal our decision to the Standards Secretariat.
John Grant, Chair, AESSC SC02-02
Reply from J. Simpson, 2011-04-18
Don't worry about the delay, to be honest I'm slightly flattered that anybody is interested in what I think!
I hadn't thought about unterminated inputs. Our implementation has the termination always present, so this was not an issue for us. I think there is a fine line between making sure that the standard is clear, and hand-holding people's designs. You would have hoped that anyone designing a MADI interface would already understand that the effect of unterminated inputs on their design should be considered.
Anyway I think that where the original paragraph gave an overall negative impression of equalisation, your revision is much more positive, which was really my main point.
Thank you for your time.
Jeff Simpson, Allen & Heath