Why AES67 was Developed?
With the rapid advancement of digital audio technology, the requirements for audio transmission in terms of quality, capacity, and latency have become increasingly stringent. Particularly in fields such as broadcasting, music production, post-production, and commercial audio sectors like live sound reinforcement, the demand for audio transmission has gradually shifted from traditional analog or proprietary formats to IP-based digital transmission. Since audio protocols from different companies are often proprietary, a unified standard is essential to achieve interoperability.
Differences between networked audio protocols
| Feature Module | AES67 | RAVENNA | Dante | QSC | Livewire |
|---|---|---|---|---|---|
| Control & Monitoring | SNMP | HTTP, Ember+ | Proprietary | TCP, HTTP | HTTP, Proprietary |
| Discovery | Bonjour, SAP | Bonjour | Proprietary | Proprietary | Proprietary |
| Connection Management | RTSP, SIP, IGMP | RTSP, SIP, IGMP | Proprietary | Proprietary | Proprietary, HTTP, IGMP |
| Session Description | SDP | SDP | Proprietary | Proprietary | Proprietary |
| Transport | RTP, IPv4 | RTP, IPv4 | Proprietary, IPv4 | RTP, IPv4 | RTP, IPv4 |
| Quality of Service | DiffServ | DiffServ | DiffServ | DiffServ | DiffServ/802.1pq |
| Encoding & Streaming | L16-32, ≤8 ch/str | L16-32, ≤64 ch/str | L16-32, ≤4 ch/flow | 32B-FP, <16 ch/str | L24, st, surr |
| Synchronization | PTP1588-2008 | PTP1588-2008 | PTP1588-2002 | PTP1588-2008 | Proprietary |
| Media Clock | 48kHz, 96kHz | 44.1kHz – 384kHz | 44.1kHz, 192kHz | 48kHz | 48kHz |
Demand for High-Performance Networks
The development of the AES67 protocol is focused on high-performance networks to support high-quality (16-bit/48 kHz and above), large-capacity (up to hundreds of audio channels), and low-latency (less than 10 milliseconds) digital audio transmission. These demanding network performance requirements can be easily met in local area networks and enterprise-level networks. However, although various network audio systems such as RAVENNA have been developed for high-performance media networks, there is a lack of a unified, standardized interoperability solution between these systems. Therefore, AES67 aims to fill this gap by identifying and recommending common protocols and operating methods to achieve interoperability among major systems
Standard Application Scenarios
The design purpose of the AES67 standard is to serve various audio distribution scenarios, especially in broadcasting, music production, post-production, and other fields. Additionally, it is suitable for commercial audio applications, including fixed installed sound systems and live sound reinforcement systems for touring performances. By providing consistency and interoperability, AES67 ensures smooth communication between various audio devices, resolving the issue of incompatibility between devices from different manufacturers.
Formation of Task Groups and Project Progress
Development of AES67 began in 2010 when the Audio Engineering Society (AES) established a standardization task group named SC-02-12-H, dedicated to developing interoperability standards for high-performance professional audio IP networks. This project was designated as AES-X192, led by Kevin Gross, a seasoned expert in media networking and the inventor of the pioneering CobraNet technology. After the project initiation, through online meetings and face-to-face discussions, the task group quickly gathered over 100 experts from top companies and organizations in the professional audio industry, eventually releasing a draft of the AES67 standard comprising over 40 pages on September 11, 2013.
Components of the Standard
To achieve true interoperability, the AES67 protocol focuses on several key aspects:
- Synchronization: defining mechanisms for a common clocking system.
- Media Clocks: specifying which media clocks must be supported and their relationship with the common clocking system.
- Transport: describing how audio data is transmitted over the network.
- Encoding and Streaming: outlining how audio is digitized and formatted into packet streams.
- Stream Description: providing information for connection management, such as network addresses, encoding formats, and source information.
- Connection Management: establishing procedures and protocols necessary for setting up audio stream connections between senders and receivers.