By now, you’ve heard that AES67 is part of the SMPTE 2110-30 standard and that all the major IP audio vendors offer this audio transport standard as part of their system.
The AES67 format will be useful for streaming audio between the control room and the master control and there’s good reason to believe that it will effectively eliminates the practice of HD/SDI audio embedding/de-embedding with video, and all the hardware that goes along with HD/SDI workflows.
There’s been a great deal of talk about AES67, but that is as far as it’s gone for most broadcasters – essentially a new standard still sitting on the dealer lot waiting for a test drive.
How easy will it be to commission AES67 in your plant?
We decided to take AES67 out for a spin to find out. Earlier this summer we did a trial run of AES67 through a large WheatNet-IP system staged at the Wheatstone factory in New Bern, North Carolina, during what we call a BLADEFest. (BLADEs are the I/O access units that make up the WheatNet-IP audio network). We do BLADEFests periodically to test our system under real-world conditions, and for this one, we added in a few AES67 devices while we were at it.
We added AES67 devices from Genelec, Ward-Beck, Dante, and Axia into the WheatNet-IP system of 12 mixing consoles, 62 hardware BLADEs (or I/O access units), 100 software BLADEs, talent stations, SideBoards, Smart Switch panels, and software including three different vendors’ automation systems. It was all tied together through Cisco and Dell switches.
We ran the system through a series of automated torture tests that included completely rebooting the system and verifying proper operation afterward. We’re happy to say that after more than 160 reboots, not a single connection failure or loss of audio occurred. We also learned a great deal about commissioning AES67 in a plant. Here are a few major findings.
Finding #1. AES67 specifies version 2 of the IEEE-1588 Precision Time Protocol, or PTP. For an AoIP system to maintain timing and stay synchronized with other AES67 devices, the system timing must be controlled by PTPv2. For that to occur there must be some device in the system that serves the role as PTPv2 timing generator to which all other devices slave their timing. Standardizing timing makes it possible to re-synchronize audio to video since every packet in the AES67 audio stream carries a time stamp. Once the PTPv2 clock is running, it’s possible to begin connecting AES67 devices to the network.
Once the PTPv2 clock is running, the system is licensed for AES67 and it’s possible to begin connecting AES67 devices to the network.
Finding #2. Before connecting AES67 devices, map out an IP and stream multicast address plan with all devices on the same IP subnet. Each AoIP vendor has their own way of allocating addresses and a plan will assure there’s no overlap and that AES67 devices will be on the same IP subnet since multicasting does not normally cross subnet boundaries. Start with the AES67 devices that are least common or least flexible in specifying or changing multicast addresses.
Finding #3. When adding an AES67 device to the network, set the system sample rate at 48kHz unless you know the device sample rate. AES67 does not require devices to support 44.1kHz and many do not. You’ll most likely find this setting option and others in the admin software that comes with the network system. For example, the WheatNet-IP audio network uses Navigator, an interface screen of which is shown below.
Finding #4. When adding an AES67 device to the network, pay attention to packet timing incompatibilities. WheatNet-IP uses 1/4 ms packet timing for minimum latency. Most AES67 devices also support 1/4 ms packet timing but some, such as Dante, do not. For those devices that do not use 1/4 ms packet timing, we enabled the AES67 1 ms Support option in WheatNet-IP Navigator, as shown below.
Finding #5. Some AES67 devices do not offer an easy way to manually manage streaming details, although these devices often can ingest these details in the form of an SDP file. In our case, we created SDP files by simply right-clicking on the desired source stream’s name in the Navigator crosspoint grid and opening a window that let us create the file.
Above are a few sample SDP files from WheatNet-IP and Dante showing multicast address, packet timing, sample rate and stream formats.
Overall, commissioning AES67 in most broadcast plants should be a nonevent as broadcasters begin adopting the SMPTE 2110 suite of standards.
Andy Calvenese is vice president of engineering for Wheatstone.
Editor's note, Finding #1 was updated July 30, per author's request.
