In This Section
SC-02-02 meeting, San Francisco, 2008-10-01
Report of the meeting of SC-02-02 Working Group on digital input/output interfacing of the SC-02 Subcommittee on Digital Audio, held in San Francisco, 2008-10-01
The meeting was convened by S. Harris, chair of SC-02.
The agenda was approved after including a request from A. Mason to discuss AES41. The report of the previous meeting, held in Amsterdam 2008-05-16, was approved without comment. For projects assigned to this working group but not listed here, see current project status on the web site No action was requested or required.
AES-R6: Guidelines for AES50 (HRMAI)
No action was requested or required
AES-2id-R: Review of AES-2id-2006: AES information document for digital
audio engineering - Guidelines for the use of the AES3 interface
Initial work is in progress, but completion of an output draft is waiting for the completion of AES3-X.
AES-10id-R: Review of AES-10id-2005: AES information document for digital
audio engineering - Engineering guidelines for the multichannel audio
digital interface (MADI) AES10
No action was requested or required
AES3-R: Review of AES3-2003: AES standard for digital audio engineering -
Serial transmission format for two channel linearly represented digital
AES3 Amendment 6 is currently in Call for Comment. Amendment 6 is expected to be published in November as the last substantive contribution to AES3 in its traditional form.
AES5-R: Review of AES5-2003: AES recommended practice for professional
digital audio - Preferred sampling frequencies for applications employing
No action - CFC on draft revision in progress.
AES10-R: Review of AES10-2003: AES Recommended Practice for Digital Audio
Engineering - Serial Multichannel Audio Digital Interface (MADI)
The meeting proposed to move the latest draft to PCFC as soon a possible.
AES11-R: Review of AES11-2003: AES Recommended Practice for Digital Audio
Engineering - Synchronization of digital audio equipment in studio
The meeting proposed to delete references to physical media in Table 1 because the increasing range of frame rates in television now make the traditional link to older systems irrelevant. However, note 1 should be extended to clarify that 30/1.001 = "NTSC".
Accepting R. Caine's recent proposed changes, and with the change to table 1 discused above, the secretariat will produce a new PWD.
J. Schmidt of ABC requested that a future version of AES11 provide an unambiguous sync phase relationship for non-integer (NTSC) plants. S. Lyman suggested that SMPTE are currently discussing sync & timing, were aware of this issue, and a solution would probably not be practical until that work was done.
AES47-R: Review of AES47-2006: AES standard for digital audio - Digital
input-output interfacing - Transmission of digital audio over asynchronous
transfer mode (ATM) networks
A PWD for draft amendment was posted 2008-07-23. No comments were raised at the meeting and it was proposed to proceed with PCFC.
AES50-R: Review of AES50-2005, High Resolution Multichannel Audio
No action requested or required.
AES3-X: Restructure of AES3-2003: AES standard for digital audio engineering - Serial transmission format for two channel linearly represented digital audio data
This draft presents, in layered multi-part form, the interface curently standardized in AES3-2003 plus its subsequent amendments. It does not intend to introduce substantive changes, but prepares this standard for the future.
The current PWDs will be updated by the secretariat to incorporate recent email amendments to create a new set of PWDs before the end of October. PCFC expected at the end of November, and a CFC before the end of December.
The meeting thanked Robin Caine for his work in producing these drafts.
AES-X139: Liaison with EBU P/AGA
Chris Chambers pointed out the recent publication of EBU technical documents on Interoperability of high-quality audio over Internet Protocol (IP): EBU Tech Doc T3326 (Interoperability), and EBU Tech Doc T3329 (informative tutorial on audio contribution over IP).
AES-X161: Digital interface for loudspeakers
Pointed out that draft IEC committee document for vote (CDV) is on the working-group document site. Any comments should be sent to the group reflector before the end of November.
AES-X182: AES/Ethernet Simple Open Protocol
This project was recently accepted for development by SC-02 and assigned to SC-02-02. Project scope: to specify a means for transmission over category 5 data cable of unidirectional digital audio and bidirectional control data. Intended applications are active loudspeakers and amplifiers for live performance and for installations.
U. Zanghieri discussed the project outline using the same presentation that was used in Amsterdam. He pointed out that this design was aimed at low-cost manufacture combined with low latency in live sound applications. The scheme uses two pairs of the data cable for AES3 audio data, and two pairs for transmission of Ethernet-compatible data. The interfaces are intended to be daisy-chained and fault-tolerant.
It was pointed out that GB Ethernet and Power-over-Ethernet interfaces use all 4 pairs for networking. Need to be careful to avoid errors due to mis-connections. Also, the relays proposed may exceed the physical design limits of Ethernet and may impose restrictions on cable run length as a result.
It was also suggested that IEEE might object to the use of "Ethernet" in a context not under their control. M. Yonge confirmed the need to be clear that any standard would not re-invent Ethernet or claim authority over existing Ethernet standards. AES50, for example, merely claims "compatibility" with Ethernet (with some restrictions and exclusions).
Harris pointed out the benefits of AES3-level simplicity; no packetization issues or clock-recovery or packet-oriented jitter issues to deal with. If the technique is useful, then the AES has a role to present a single clear way to do this.
M. Poimboeuf feels this could solve a problem for latency in live sound.
The meeting proposed to form a task group, including Zanghieri, Poimboeuf, and Gross in the first instance. Participation from others is invited.
Harris questioned the lack of a control protocol in the proposal. How would this affect the plug-in compatibility? Discovery protocol will be important. Reliable operation on plug-in would be important for the success of the standard.
Gross said that a complex discovery protocol would be difficulty, but restricting the size of the Ethernet part of the network to a finite number of nodes would help to support a simpler scheme. Zanghieri pointed out that no eternal PC on the network should be needed - the nodes themselves handled discovery.
Harris suggested a pair of documents would be useful: a standard, and an informative document to guide the use of the standard.
Harris also suggested that this project be promoted to interested parties to encourage contributions from potential users. It was proposed to produce a standards report in the first instance to present the purpose and justification for the standard, and to draw up parameters for the draft standard to follow. Zanghieri offered to draft this report for discussion within the working group.
J. Yoshio reported on progress in IEC. A number of new parts are being introduced to IEC 61937. An amendment to IEC 61958-3 digital audio interface, consumer - will be discussed at the liaison meeting. IEC 62574 is a proposal for unified channel assignment.
C. Chambers reported that IEC 62379, "Common Control Protocol, Audio" has recently been published. The meeting requested to see a copy of the draft for information.
AES41: Recoding data set for audio bit-rate reduction
Mason raised a possibility for extending the technique used in AES41. SMPTE 2020 discusses carrying Dolby-metadata in a video signal. There's a problem if there is no video signal in the chain to carry the metadata. It could be possible to carry the metadata in a coded audio bitstream in AES41-form for audio-only applications that will not have video plant? It was proposed that a task group (Mason and Lyman initially) will discuss the project with a view to creating a more formal proposal that would either seek to amend AES41, or to create a new document.
Audio over NGSDH
Chambers raised the question of professional audio on newer telecommunications structures for broadcast infrastructure backbones? How about professional audio over next-generation SDH (NGSDH) for audio infrastructure over the wide area with high quality and low latency? In telecommunications, the NGSDH format is emerging to provide an alternative to the older ATM interface. A video interface already exists (ITU - in use in Italy for RAI). A suitable audio format could be similar in scope to AES47. Gross understood that the IEEE is working on higher network layers, but there's a need to specify transport layers.
Chambers volunteered to write a report outlining the purpose and value of such a project.
There was no new business
The next meeting will be scheduled in conjunction with the AES 126th Convention in Munich, Germany, 2009-05.
Thanks to Mark Yonge for writing the notes.