How much do you know about AES67? Our friends at Wheatstone breakdown what you need to know.
AES67-2013 may be the new IP audio standard that everyone’s talking about, but it didn’t take long for the various brand permutations to suck up all the oxygen in the room. These aren’t standards per se. They are IP audio network systems, WheatNet-IP included, that incorporate AES67 as a subset among other functions and connectivity options. So while you will have to forgive us for proselytizing our respective brands, it’s important to understand the significance of so many audio networks adopting and sharing this interoperability standard.
AES67 is everywhere. It’s in every major audio network, including our WheatNet-IP, which means that you’ll be able to transport audio between all these systems and other devices and peripheral gear that are connected to them. This IP audio transport standard was ratified in 2013 by the AES X-192 task force, of which Wheatstone was a member.
But, AES67 is by no means a complete interoperability standard. It doesn’t provide for discovery and control, both of which are needed for any kind of inter-functionality to take place. These standards are in the works, but in the meantime, turning devices on and off, controlling peripheral gear from the console, signaling when a source is ready for air play, and controlling the playout system with a fader – these are all functions of WheatNet-IP and similar audio networks. In the case of WheatNet-IP, for example, a single Ethernet cable carries the real-time audio stream as well as network and device control messages and other metadata. AES67 covers the audio streams only.
With all this in mind, here are straightforward answers to the more common questions our engineers receive on AES67.
Why do we need AES67?
IP networking is easily one of the most ubiquitous technologies found in the world today. IP audio network manufacturers are able to take advantage of, and share in, many, many proven standards as a result. So, why do we need one more standard? Because the rules of IP packet distribution are not friendly to real-time audio. Synchronizing large amounts of data is the biggest problem. In the IP network, packets aren’t necessarily routed based on which packets were created first. That works fine for a typical office network, but without some sort of deterministic routing for the heavy traffic loads of the audio network, packets can become jumbled and delayed. This can cause jitter and packet loss or dropout. Audio network makers have had to work around this problem with tools like buffering and QoS to assure continuous audio transport. No two manufacturers solve this problem the same way, which has made it difficult for them to exchange audio between them.
What does AES67 do?
Almost all audio networks use a standard IP protocol called RTP (Real-Time Protocol) to create the proper packet order. RTP provides identification in the packets about their creation time and order but, for all the reasons stated above, it has been up to the IP audio network manufacturer to extract this information and to recreate the audio data and timing. Each differs in the specific packet loading, timing and synchronization mechanisms within the protocol.
AES67 has come along to provide the common synchronization, clock identification, session description and other interoperability recommendations we can all share. AES67 adapted the PTPv2 (Precision Time Protocol - IEEE 1588-2008) standard as the master clock reference, so we can more easily transport audio between our various systems without jitter, delay and data dropout. Check out this AES link for a full description:
Does AES67 provide for discovery?
No. AES67 does not provide for a standard way to find and add devices to a network. Discovery is left up to each individual manufacturer, although most of the major players take a similar approach to finding and labeling components in the network. Most designate extra packets on the network to communicate discovery data and display it seamlessly to all users with signal names and other information easily created and recognizable to broadcasters.
Does AES67 provide for control?
No. AES67 is an audio transport standard only. Another standard or other standards are needed for full interoperability of the control features of various audio networks. The AES-X210 task group, of which Wheatstone is a part, was formed for this reason. We recognize that gaining access to hundreds of channels of audio on a network is useless if you can’t route them, turn them on or off, fire their playback, or turn an ON AIR light on when needed. Currently, to accomplish this, IP audio network manufacturers use packets to communicate command and control. Each system is different, and sometimes an ancillary PC is used for this and sometimes the intelligence is built right into the network devices, as is the case for our WheatNet-IP system.
Control is built into each WheatNet-IP connection point that is shared with other IP connection points across the network, giving you access to all sources at once as well as the presets and any associated logic that go along with each feed for controlling mic ON/OFF, changing remote mic settings for IFB, and processing and other parameters. (There we go again!)
Does AES67 pay it forward?
Yes. AES67 is extensible, meaning that you will be able to add to it as situations change. Any standard that results from AES-X210 or a similar group will add on to, not replace, AES67.