In This Section
- Networks - High-performance streaming audio-over-IP interoperability; AES67-xxxx DRAFT REVISION proposed for comment
- Universal jack for 6,35 mm plugs; AES-14id-2010 proposed for reaffirmation
- Measurement of digital audio equipment; AES17 draft revision proposed for comment
- Spatial acoustic data file format; AES69-2015 published
SC-02-12 meeting, New York, 2013-10
Report of the meeting of the SC-02-12 Working Group on Audio Applications of Networks of the SC-02 Subcommittee on Digital Audio, held in New York, NY., US., 2013-10-19
The meeting was convened by chair R. Foss.
The agenda and the report of previous meeting, held in Rome, 2013-05-06, were approved as written.
Projects assigned to this group but not mentioned here had no action requested or required - see www.aes.org/standards/meetings/project-status.cfm for details.
AES58-R: Review of AES58-2008: AES standard for digital audio - Audio applications of networks - Application of IEC 61883-6 32-bit generic data
Project scope: to describe unique requirements for professional audio carried over 1394.
Discussion: Foss indicated that this related to the streaming of control data (apart from MIDI) over IEEE1394, and that the standard was complete. There was no further discussion relating to this standard.
AES64-R: Review of AES64-2012, AES standard for audio applications of networks - Command, control, and connection management for integrated media
Project scope: This standard specifies:
1. A set of structured Internet Protocol-based messages and a specification of the messages that can be used to control single or groups of parameters, and to monitor these parameters. The parameters are associated either with typical signal processing functionality within audio and other media devices, synchronization between such devices, or connections between such devices.
2. A definition of indexed parameters and a specification of the message format for such messages.
3. A definition of peer-to-peer grouping and master-to-slave grouping of device parameters, and a specification of the messages required to implement such grouping.
4. A definition of modifiers, and a specification of messages required to create and control such modifiers.
5. A definition of desk items as a means to extract graphical user information from a device and allow for the control of the device via the extracted graphical controls.
6. A definition of security levels, and a specification of messages required to set and get such levels.
Discussion: Foss indicated that Secretariat comments on parameters with Global Unit values had been addressed, and that updates related to parameter snapshots and bulk parameter 'pushes' for monitoring purposes would be presented to the working group in the near future.
AES-R10: AES standards project report - Use cases for networks in professional audio
Project Scope: To identify and clarify use cases for networks in professional audio applications for Recording, Live sound, and Installations
Discussion: K. Gross agreed to look at the report, edit it and possibly update it further. He is currently busy with similar work in conjunction with the IETF and other organizations. Anyone else with an interest in this report should contact Gross.
AES67-R Review of AES67-2013 High-performance streaming audio-over-IP interoperability
Project Scope: The goal is to standardize the format for audio data within IP packets. Currently there are a number of ways of transmitting uncompressed audio over IP. There are even a number of ways of transmitting audio using RTP.
Discussion: Gross discussed the goals of the standard. He indicated that there is dependence on a clock source draft standard that is being created by the IETF. This draft has moved out of the working group and is under review. He pointed out that the standard does not require or recommend any particular discovery method.
Gross discussed AES67 project liaisons, and indicated the importance of synchronization standards being in line with SMPTE standards. He spoke of the complimentary nature of ACIP standards and particularly the need to be aware of ACIP2. Gross agreed that he would be the liaison person for SMPTE and IETF, and P. Stevens would be the liaison for ACIP.
AES-X075: Liaison with IEC TC100 for IEC 61883
Project Scope: to prepare recommendations and assist the work of IEC TC100SC-02-12 regarding the development and maintenance of relevant parts of IEC 61883. Any assigned task group shall report project progress to SC-02-12 and shall ask SC-02-12 for its advice on content. Administrative review of the project shall follow AESSC rules.
Discussion: J. Yoshio presented a liaison report that contained an IEC standards update and described work done on TC100 specifications related to SC-02-12.
IEC 61883-6 The revised items for the edition 3.0 are multichannel assignment, copy control information of DTCP+, and editorial corrections. The document is still being edited by J. Fujimori.
IEC 61883-8 (BT. 601) Edition 1.0 Amendment 1 status. The CDV is approved, and editorial comments were solved. The final document was submitted and it will be published. The amended items are copy control information of DTCP+.
TC100 liaison with IEEE1722. There were fruitful discussions, particularly related to car applications, with Aaron Gelter who is the working group editor for IEEE 1722a. Also discussed was the transmission of Dolby E via IEEE1722.
AES-X137: Liaison with 1394 Trade Association (1394 TA)
Discussion: M. Lave, the 1394TA liaison said that the organization was undergoing change and that there had been no recent technical activity in the area of audio. The 1394TA is working out a way for access to the 1394TA documents, and also how the documents can be maintained without work on the part of the 1394TA.
AES-X170B: AES standards report - supplementary information on AES-64.
Project Scope: The objective of this information document is to present additional tutorial information pertaining to particular aspects of the X170 specification, in particular:
1. The origins of the 7-level hierarchy.
2. The creation and processing of X170 messages.
3 Peer to peer grouping and master/slave grouping of device parameters.
Discussion: Foss indicated that there had been no further work on this document.
AES-X210A Open Control Architecture - Framework and object model
Project Scope: To specify a scalable control-protocol architecture for professional media networks. The initial version will address audio aspects only, but it is intended ultimately to expand the scope to video through collaboration with a video-oriented standards body such as SMPTE. Note that OCA is a control protocol only, and does not aspire to provide streaming media transport. It is intended to cooperate with all kinds of media transport architectures.
Discussion: J. Berryman, the task group leader, presented a report on the task group meeting that was held previous to the working group meeting. He indicated that the draft document is complete from the point of view of the task group, and would be brought into the working group. However, this document could not be published as a standalone document, it needed to be published together with three other documents from projects AES-X210B, AES-X210C and AES-X210D. The expecation is that all documents will be complete before the end of 2014.
AES-X210B Open Control Architecture - Class tree
Project Scope: To be confirmed
Discussion: There were a number of updates to the class tree within the OCA Alliance. There would be annual updates to the class tree.
AES-X210C Open Control Architecture - TCP/IP communications protocol SC-02-12
Project scope: To specify a scalable control-protocol architecture for professional media networks.
The initial version will address audio aspects only, but it is intended ultimately to expand the scope to video through collaboration with a video-oriented standards body such as SMPTE.
Note that OCA is a control protocol only, and does not aspire to provide streaming media transport. It is intended to cooperate with all kinds of media transport architectures.
status: Project AES-X210, "Open Control Architecture (OCA)" initiated 2012-10-08
AES-X210D Open Control Architecture - Minimum implementation
Project Scope: To be confirmed
Liaison with Ethernet AVB: M. Mora, who leads this liaison, was not present at the meeting. Foss indicated that IEEE1722.1 was now a published standard. Gross indicated that there were annexes to indicate how to enable Ethernet AVB and AES67 networks to cooperate, and that there should not be a sense of "AVB versus AES67".
Liaison with MPEG: J. Grant indicated that there is not much happening in MPEG, although MMT (MPEG Media Transport) appears to be moving forward, and there are drafts being voted on. There wasn't anything in the drafts that he needed to bring to the attention of the group. He gave a brief background to MMT.
Liaison with IEC 62379: Grant spoke briefly about 62379 part 5, sub part 2 that is almost finished. This is a signalling protocol for future networks. Stevens reported on part 3 that has gone to ballot this year. Part 2 has not been updated (relevant to audio). Part 7 went through its ballot and is on its way to being published.
Gross spoke about the SMPTE/EBU joint task force for networked media (JT-NM), who are collecting use cases for networked media, and are asking for responses from network providers. Gross has created a Google doc for AES67 responses. Editing permissions can be obtained from Kevin.
J. Berryman pointed out that there would be a 'gap analysis' following initial submissions, the gap being between what was required and what was currently available.
There was a discussion around a interoperability 'plugfest' for AES67 along the lines of the ACIP and the PTP plugfests. There was an offer from Swedish Radio to host such a plugfest. It was agreed that it would be best to have a venue that had the necessary equipment to test interoperability in a meaningful way. Gross pointed out the need to have AES67 implementations to test. Also required is a clear testing protocol. It was proposed that the current task group reflector be used for generating ideas relating to conformance testing. Kevin, in the first instance, agreed to scope the task group's goals and lead the group, while the secretariat agreed to set up a new project for the group in due course.
Berryman raised the issue of device discovery. Transport and control protocols need a name service. Somewhere, typically, there is a database of names and addresses. Bonjour is a name service that gets populated automatically. Berryman gave a multiple subnet network example to illustrate the issue. He believed that there needs to be a single approach, possibly at the application layer that can allow both transport and control protocols to access a name service. He felt that there should be a standardized interface to the name service.
Gross indicated that the X192 project had explored this issue, and that there was not an easy solution. P. Treleaven indicated that the SMPTE version of control did have a section dealing with discovery. Berryman agreed to determine whether he would be able to initiate and lead a project on this topic.
No new business was proposed.
The next face-to-face meeting will be held in conjunction with the AES 136th Convention, to be held in Berlin, Germany, 26 to 29 April 2014.