Viewpoint: The Potential and Reality of AES67

Interest is growing in the broadcast industry about the AES67 standard, and its potential benefits as users transition from wired to networked audio systems.

With a number of different networking options available, broadcasters welcome a standardized approach that supports basic interoperability between different equipment vendors, who have historically offered their own solutions.

AES67 is recent standard that aims to accomplish this task. The AES67 standard is a networked audio interoperability specification developed by the Audio Engineering Society. It describes techniques for exchanging digital audio on a TCP/IP networking using RTP, or Real-time Transport Protocol. Additionally, AES67 specifies particular implementation constraints to facilitate interoperability between implementations.

Great Expectations

AES67 promises basic interconnectivity at its core, and has fairly modest and achievable goals. Primarily focused on the audio networking transport element, AES67 does not specifically address system control, signal routing or channel labelling. For audio quality, it requires 48kHz, 24-bit stream with one-millisecond latency as a lowest common denominator. AES67 allows for, but does not require, support for higher sample rates and different bit depths, which means that supported audio formats may vary between devices in the ecosystem.

Since AES67 is essentially a set of network standards around how audio channels move across an IP network, it represents a pragmatic evolution in audio networking. Unlike previous specifications (e.g. AVB), AES67 offers a standards-based way to deliver multichannel audio between devices across a network without requiring specialized network equipment. This is significant as it is the first specification to achieve this goal. Like Dante, the AES67 transport operates with common off-the-shelf switches. Therefore, we expect AES67 deployments will not face the adoption delays that have challenged AVB rollouts.

Device Discovery in the AES67 Standard

However, there appears to be a potential mismatch between expectations of AES67 and its true scope, particularly in the area of device/channel discovery. Many broadcasters and manufacturers are unaware that the AES67 standard does not require a common discovery method to be implemented.

This has fostered a situation of uncertainty. Most networking vendors have proprietary systems to discover hardware-enabled components that are part of their ecosystem, but do not discovery components enabled with another vendor’s networking software. This is not to say that AES67 cannot be used to connect audio streams without a discovery protocol – it can, but doing so will be a manual process specific to each vendor.

The danger is that while AES67 does not specify nor require a common discovery system, many broadcasters expect that AES67 devices will be naturally discoverable once deployed. At present, this is simply not the case.

In lieu of mandating a discovery protocol, the AES67 specification instead offers four possible options for discovery protocol implementation. An AES67 implementation using one of these four options cannot discover implementations using a different discovery option. Each discovery solution operates in its own world. In addition to the four suggested options, other companies have created their own discovery solutions for use with AES67.

This creates several problems. First, each additional incompatible discovery solution creates islands of AES67 devices that can only discover each other. From a purely engineering standpoint, it is possible to manually configure these various devices to speak to each other over a common network, but this will be a complex, time-consuming data entry processes – a task that will excite very few engineers and integrators.

A close examination of the four discovery options in AES67 shows only oneoption based on mature, published standard specifications: Session Announcement Protocol (SAP).

For AES67 devices to be discoverable as users expect, the industry must settle on a small subset of discovery protocols for use with AES67. Ideally, that subset is exactly one protocol. Audinate has selected SAP as the discovery protocol mechanism for use with AES67 transport in Dante because it is the only non-proprietary, mature, published standards-based option described in the AES67 specification.

The benefit for the broadcaster is that Dante devices supporting AES67 can discover other AES67 devices using supporting the SAP discovery mechanism. Dante devices supporting AES67 announce their AES67 audio using SAP and Dante Controller can discover non-Dante AES67 devices that support SAP.

It is our hope that networking vendors industry-wide will coalesce around this standards-based protocol from the IETF – the body that defines all Internet protocols – to simplify AES67 discovery across any audio networking ecosystem. This path is the most certain to meet the expectations that broadcasters have about how AES67 interoperability should ultimately work: A system that is fully discoverable, easy to patch and easy to deploy without manually entering a series of complicated letter and numbers to enable interoperability.

Aidan Williams, CTO of Audinate.

Aidan Williams, CTO of Audinate.

The Benefit of Experience

Discovery concerns aside, Audinate sees the long term viability in AES67 compared to earlier protocols. In creating the AES67 interoperability standard, the AES organization utilized proven existing standards which mitigates the risk of the technology.

It is important to note that AES67 is not a complete audio networking solution. Leading audio networking solutions like Dante still have a key role to play offering additional features, management tools and support, which greatly simplify audio networking for users and manufacturers. This includes the matrix-style signal routing software, virtual soundcards, network health and clock status monitoring, real-world naming for devices and channels, and much more.

In contrast, AES67 just specifies the baseline connectivity of audio streams, and more closely resembles an Audio over IP version of MADI or AES3. It focuses on how audio channels move through the network between points without defining how routing or switch-defined control may occur.

Audinate has taken the step of adding AES67 as a feature to Dante.As an IP-based standard, AES67 is a comfortable fit for Audinate since Dante has always been built upon Layer 3 networking (the architecture required for pure Audio over IP transport).

Audinate will continue to be involved in the development and tracking of new standards and protocols that further the possibilities of audio networking for TV and radio broadcasting. If one thing is certain, the industry will continue to develop new standards that require implementation in a sensible way, and it is important to have a robust networking solution that can evolve to incorporate the latest standards.

You might also like...

IP Security For Broadcasters: Part 8 - RADIUS Network Access

Maintaining controlled access is critical for any secure network, especially when working with high-value media in broadcast environments.

Thoughts On NAB 2022

NAB happened! Yes, footfall was inevitably down and there were fewer vendors exhibiting, but the show went on. And what a great success it was too.

Audio Consoles Focus On AoIP Networked Production At NAB

Like most equipment now being marketed to broadcasters these days, audio consoles continue to improve in the area of audio over IP (AoIP) networking and remote production workflows. Indeed, efficiency, flexibility, and remote as well as distributed production are at…

IP Security For Broadcasters: Part 7 - Operating Systems

As well as providing the core functionality of a computer, operating systems have the potential to be a primary issue for security and keeping hackers at bay.

TDM: The Third Way - Part 2

In Part 1 we looked at how TDM provides a compromise to deliver the flexibility and scalability of IP, while at the same time providing the ease of use of SDI. In this article, we look at how TDM deals with…