The idea of moving audio over an Ethernet cable may be a difficult concept for some to grasp, but audio over IP (AoIP) has matured to the point that it’s only a matter of time until it becomes standard in television facilities.
Speakers, microphones, mixing consoles, intercoms and other systems are all beginning to ship with the technology built-in but broadcasters working in facilities that are currently embedded SDI, discrete AES or MADI may have trouble figuring out the reasoning behind it.
Primary drivers include the ability to utilize existing network infrastructure to grow and upgrade facilities without adding significant cabling and the prospect of carrying hundreds of audio channels over a single cable. However, there are some caveats to making this work in a real facility. Though many systems are already in place and working well, these tend to be end-to-end solutions from one manufacturer.
At some point these systems will need to interface with systems from other manufacturers as facility upgrades are made. In this column we’ll look at the problems presented by interfacing these systems and see whether AES67 offers any help.
AOIP SOLUTIONS
The most popular AoIP solutions currently in use are provided by just a handful of companies: Dante from Audinate; Ravenna from ALC Networx; Telos’ LiveWire; and WheatNet from Wheatstone. Each one of these companies offers a competing and not wholly compatible version of the technology.
Companies numbering in the hundreds have signed on as technology partners and are releasing products that support one of the technologies, but not the others. This lack of compatibility was frustrating to those ready to begin implementing AoIP. It also seemed destined to fragment the industry and possibly even derail the technology.
Fortunately the Audio Engineering Society saw this train wreck coming and decided to do something about it. A working group called “X192,” headed by CobraNet Creator Kevin Gross, was established and within just a few years the AES67 interoperability standard was released.
All of the main solution manufacturers were represented in the group, along other audio professionals, and they worked together to come up with a single standard that all could comply with. It certainly helped that the working group decided from the outset that it would not invent new technology, but would utilize the mature standards already in place in the IT industry and determine which of those standards worked best for audio.
AES67 uses IEEE 1588-2008 for clock, DiffServ for Quality of Service (QoS), Real Time Protocol (RTP) for transport, and Session Initiation Protocol (SIP) for connection management. Specifications for the audio are 96 kHz, 48 kHz or 44.1 kHz linear PCM at 16 or 24-bit, carrying from one to eight channels.
Because AES67 is designed to work on Layer 3, solutions based on it should be able to cross subnets, allowing for the possibility of large audio networks. Exceptions are made throughout AES67 for Audio Video Bridging, another emerging technology designed to carry audio as well as video over IP. AVB has some additional overhead requirements intended to make it more robust, but covering the details and pros and cons of AVB are outside the scope of this column.
INTERCHANGEABLE DEVICES
Even though AES67 establishes an interoperability standard it doesn’t mean every AoIP device will necessarily work interchangeably with every other. Audio streams will work between devices and clocking should be solid, but the systems won’t necessarily know much about each other.
One piece absent from the AES standard is discovery—omitting it was necessary to complete the standard in a timely manner—and all of the current commercial products already have their own version. Dante devices know about other Dante devices; Ravenna and LiveWire devices know about their own systems, but they don’t necessarily know about competitors’ products.
Also, even though they were part of the working group and made no mention of patent concerns during the review period prior to publication of the standard, Audinate now states that portions of the standard infringe on patents they hold.
This patent claim has put a bit of a damper on enthusiasm for AES67, though Telos Systems has released a statement claiming there’s nothing to worry about as they’ve been using the technologies in AES67 in their products since 2003, several years prior to the creation of Dante.
Regardless, the prospect of paying a licensing fee or going to court will give any manufacturer reason for serious contemplation before jumping into the AoIP pool.
The good news is that placing AoIP devices on a typical network and having enough bandwidth for audio and other traffic isn’t a problem, especially as network speeds increase. The most difficult part of a successful AoIP implementation may actually be obtaining cooperation from the IT department.
There has been much discussion on the topic of whether television engineers must now become network engineers as well and this may depend in part on the relationship between engineering and IT. It is critical that these groups work hand in hand to gain mutual understanding of issues such as security restrictions, media prioritization and guaranteed network uptime.
If they can’t work collaboratively then it may be necessary to build a separate network for media, which eliminates all cost savings realized by moving media over existing network infrastructure. The role of television engineers has changed significantly over the past two decades anyway: first with the requirement to support consumer-grade systems for production; then with the move to servers in tapeless workflow; and now as media becomes IP-centric.
Even if every engineer on staff doesn’t need to be CCNA or CompTIA+ certified, insuring that some of them have a deeper knowledge of networks and IP technology is an excellent way to solve problems quickly and maintain system uptime.
AoIP is here and, with SMPTE 2022 being fleshed out, video over IP is on its heels. Successful implementation of IP media technology will depend on understanding its current limitations, planning in advance how best to implement it, and by preparing the technology teams that will have to make the implementation work.
Jay Yeary spends his days working as a broadcast engineer for a large U.S. media company. He can be reached through TV Technology or via Twitter at @TVTechJay.
