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 DRAFT AES50 document
Comments to date on DRAFT AES50-xxxx, AES standard for digital audio engineering - High-resolution multi-channel audio interconnection (HRMAI), published 2005-03-08 for comment.
Comment received from M. Willis, 2005-03-08I feel very strongly that without attempting to quote all applicable (but unaware of) patents, you should identify the patents that are known about. I presume from your comments about patents, that Sony (or someone) has patents that will come into force with this standard, if so I believe it is your duty as professional engineers to disclose this information. Otherwise, you are asking for people to make uninformed suggestions / acceptance and this 'standard' would be no more than a data sheet for the patent. A nice trick if it comes off.
On the substance of the document.
- Why a standard defining something which is so OLD TECH? This gives no more data than old MADI, which was also approx 100Mb/sec, point to point. Why not just define a Cat5 pinout / physical layer for AES10/MADI. Then all that wealth of existing product can be converted very simply etc.
- As it is point to point, it suggests that it is aimed in broad terms for connecting IO to processing. In my opinion 26 channels at 96kHz doesn't have enough bulk, and not being a network, or compatible with Cat5 infrastructure (switches and bridges.. other ways of getting more than 100m) already limits the appeal. I suggest you work on a standard that uses 1Gbit technology
With best regards
Solid State Logic Ltd
Reply from standards secretariat, 2005-03-16Dear Matthew,
I believe that the issue of patent policy is appropriate to be answered by the secretariat as it concerns the policy and procedures set down and approved in the rules of the AES Standards Committee and are separate from consideration of any technical issues concerned with this Call for Comment.
The AESSC patent policy has not changed for many years and is openly published on the AES Standards web site. This policy is in line with other public standards bodies, including ISO and IEC.
Where patents are known, the AESSC patent policy requires that a patent holder must provide a statement that the holder will be willing to negotiate worldwide licenses under his rights with applicants throughout the world on reasonable and non-discriminatory terms and conditions that shall not inhibit the use of the standard.
We have indeed received, and hold on file, such a statement on behalf on Sony Pro Audio R&D Dept. covering Sony patents in the area of this proposed standard. The AESSC patent policy is satisfied accordingly.
Beyond such disclosures, it is clearly impossible for the AES to identify all patents that may in the future be used to support claims directed at implementations of a standard. It is similarly impossible for the AES to provide any meaningful warranty on this matter, especially where individual implementations may vary. This must be a matter for the proper diligence of the implementor.
Accordingly, each AES standards document contains the wording: "Attention is drawn to the possibility that some of the elements of this AES standard or information document may be the subject of patent rights other than those identified above. AES shall not be held responsible for identifying any or all such patent rights."
I hope this answers your comment on patent policy issues. You will be hearing soon from the chair of SC-02-02 regarding the technical matters raised in your comment.
Audio Engineering Society Standards Manager
Reply from J. Grant, 2005-03-18Dear Mr Willis,
On the question of the relationship to AES10 (MADI), AES50 would be appropriate for applications that require facilities (mainly those listed in the bullet points in the Introduction) that are not provided by AES10. For those applications that do not require these facilities, AES10 would continue to be appropriate. We continue to maintain AES10 and AES-10id and there is no intention to withdraw them. It may well be that 100Base-T and/or 1000Base-T physical layers would be a useful addition to AES10, and you are very welcome to propose such a project using the procedure documented at http://www.aes.org/standards/b_policies/project-initiation.cfm
It is likely that Task Group SC-02-02-H will go on to develop a Gigabit version of AES50, and you are welcome to participate in work that by joining Working Group SC-02-02 as described at http://www.aes.org/standards/b_policies/aessc-membership.cfm
On the question of the wording of the Introduction, I agree that the current text does not adequately describe the relationship between AES10 and AES50, and suggest the following editorial change for the paragraph following the bulleted list:
"HRMAI is a high-performance point-to-point audio interconnection, rather than a network (although the auxiliary data may operate as a true network, independently of the audio). It is thus an alternative to AES10 (MADI). AES10 lacks many of the features listed above, which are enabled by developments in underlying technology in the thirteen years since AES10 was introduced. However, for applications which do not need these additional facilities AES10 will continue to be appropriate."