At this year’s NAB Show, I was engaged in a discussion about audio over IP with Phil Wagner, recently named president of Apogee, when he mentioned that no one was really discussing how to merge the technology into existing television environments. My own columns have been pointed more toward implementing it into new builds.

THINGS TO KEEP IN MIND

There are really just a few key things to keep in mind when tossing AoIP equipment into the technology mix of a current broadcast plant, but with SMPTE ST-2110-based facilities coming online and AoIP beginning to manifest itself in a very physical sense, this seems like a good time to look at them.

Just as we’ve done since television audio became digital, everything in the plant needs to be referenced to the same master clock. This has traditionally meant providing either black, tri-level, word clock or AES reference (DARS), but network connected devices—surprise—look for their clock on the network, which means we now need to provide them with an IEEE 1588 Precision Time Protocol (PTP) clock, which has been referenced to the house master. In the past this might have been achieved with a master clock from the IT world, but broadcast device manufacturers now provide master sync generators that include PTP alongside standard reference signals. Reference remains critical because the audio going through those network cables is still digital, so nasty tics, pops or complete lack of audio is the result when the reference clock is missing or incorrect.

Choosing a specific AoIP technology can seem like a daunting task since incompatibilities remain even with the publication of the AES67 standard. Remember that AES67 is not an end-to-end solution but is a defined set of internet protocols that, if followed, will allow audio to pass from one AoIP device to another. The good news is that virtually all AoIP equipment manufacturers ship their newer products with an AES67 compatibility mode of some sort, which ensures that audio will pass when connecting a box with one AoIP technology to a box with a different AoIP technology.

The bad news is that the audio is all that is guaranteed. Sticking with a given AoIP technology, Dante, LiveWire, Ravenna or WheatNet for instance, provide a more end-to-end solution so that all AoIP equipment on the network is aware of each other and information can be shared between them. It also means having full control of those devices, allowing routing and management. Mixing AoIP technologies doesn’t preclude the possibility of doing any of these things, but the lack of information sharing between technologies can make it very, very difficult.

OPERATING IN AES67 MODE

Careful planning is the best course of action before heading down the AoIP road. Since AES67 is the PCM audio transport of ST-2110, any AoIP devices in the broadcast chain will most likely need to operate in AES67 mode, so it is necessary to determine what, if any, features are lost when switching devices to this mode. Since discovery, control and management are not part of AES67, it is also critical to determine how this will be done prior to adding AoIP devices to the plant.

As previously mentioned, sticking with one technology or manufacturer will solve this problem, but this may not provide all the necessary pieces. There are now some third-party software products that promise to make differing AoIP solutions work together despite their differences, but a demonstration of the software controlling actual hardware seems in order before committing to this.

A solid solution seems on the very near horizon however, and it is already part of the ST-2110 package of standards. Obviously, ST-2110 will need discovery and registration, connection management and control, so the Advanced Media Workflow Association (AMWA) Network Media Open Specifications (NMOS) IS-04 and IS-05 have been chosen to solve those needs for ST-2110 devices. This means that AoIP devices in television facilities will use AES67 for audio transport, IS-04 to locate each other, and IS-05 to connect. Actual implementation of these specifications will be through additional software, but this is the current solution planned for SMPTE ST-2110.

A temporary workaround to the lack of discovery, connection and control across all AoIP technologies is to build an AoIP system from a single technology, then isolate this AoIP island from the rest of the plant with the exception of converting signals going in and out of these rooms. This could work for an audio suite (or group of suites) or even live mix rooms where IO to the room is self-contained and does not need to interface with other IO other than for ingest and playout. Outfitting professional broadcast audio consoles (and some semi-pro models) with AoIP alongside SDI, MADI, AES, analog IO as part of the system’s configuration is becoming standard practice. Achieving the same thing in video edit suites and the greater facility will prove a bit more difficult, and will involve more interstitial pieces. But again, advance planning is key, and part of that planning should be looking toward the facility’s future and not just its current state.

Probably the easiest part of adding AoIP devices to a television facility is connecting existing audio and networked audio devices together. There is more to it than just plugging in Ethernet cables for the AoIP devices themselves, since they need to be set up properly on the network. The type of network and its particular setup will determine how complex this actually is. Yet when it comes to interfacing AoIP devices with traditional audio devices there are plenty of solutions available of all types.

Attention needs to be paid to the underlying technology and whether it has an AES67 mode, but not every piece will be part of the broadcast chain.

Jay Yeary is a television engineer who specializes in audio. He can be contacted throughTV Technologymagazine.

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. 

NEW BERN, N.C.—Wheatstone will use the IBC Show platform to feature its WheatNet-IP system and its AES67 compatibility and IP audio networking capabilities for radio and television environments.

Wheatstone plans to demonstrate WheatNet-IP’s AES67 compatibility in an overall system based on SMPTE ST 2110 final draft standards. This will be included in the larger IP Showcase that will take place during the IBC Show, which will be held in room E106.

Wheatstone will also display WheatNet-IP and some of its other products at booth 8.C91 during IBC 2017.