WHEAT:NEWS TV NOVEMBER 2018 Volume 5, Number 11
Why AES67 is the Important Audio Standard
Standardization is the reason you can fly across the country, hop in any rental car, and drive off without having to read through the operator’s manual. It’s why you can plug your phone into any USB port to charge, and why you can access your email, your texts and your social media from anywhere, regardless of wireless carrier or make of phone.
It’s why broadcasting exists today and why the future of our industry continues to shape-shift into smart TVs and radios, OTT, and VR and AR. Every new advancement starts with a standard, and for audio, the future begins with the AES67 standard.
AES67 was ratified in 2013 as an interoperable standard for transporting audio between different IP audio devices. It is a layer 3 protocol suite now supported by all the major IP audio network manufacturers, including Wheatstone. Additionally, AES67 is specified as the audio streaming format by SMPTE ST 2110, which is another important suite of standards that will provide the structure for an all-IP studio where separate video, audio and data streams are created, carried, and synchronized seamlessly for a multitude of delivery methods and purposes. AES67 helps do away with the tedious and expensive practice of HD/SDI audio embedding/de-embedding with video, and frees up broadcasters to add, manipulate and manage audio tracks independent of video.
Our VP of Engineering and Technology Andy Calvanese goes into a few of the issues AES67 solves. You’ll also find a link at the end of this article that will take you to useful tips on commissioning AES67 in your plant.
It’s About Timing...
One of the key differences between various IP audio network systems is timing, and it’s an important difference. The AES67 standard was created to keep disparate audio devices synchronized so audio would play back without clicks and pops due to sample rate and timing mismatches. For example, Wheatstone’s I/O BLADEs (the I/O access units) in the WheatNet-IP audio network all synchronize their internal clocking to a special signal that the system distributes to every BLADE. We call that signal the “metronome” and we send it around the network many times per second to keep all of the individual clocks in BLADEs in sync with each other. We developed this method of synchronization back in 2004 when we designed WheatNet-IP. Other vendors did something else. We each did our own thing because back in the day, there was nothing suitable for the purpose; we had to invent something to make it work.
Without AES67, WheatNet-IP BLADEs can’t synchronize audio with another system’s node and vice versa without pulling an AES3 signal from one system and patching it into the other so that the second is slaved from the first. Now with AES67, we have a method to share synchronization amongst devices directly. We can use the standard timing protocol that has come out in recent years, IEEE-1588, also known as the Precision Time Protocol, or PTP. In fact, the standard specifies a particular version of this protocol known as PTPv2.
...and Packet Structure
Since all the common AoIP systems use RTP to transmit audio packets on the network, it’s important that the transmitting device and receiving device use the same system for filling and decoding the payload. Otherwise it’s indecipherable. There are many different ways this can be done. What AES67 does is to specify a single common packet structure that must be used; this is the 1msec packet timing you see in all of the specifications and this is what makes interoperability possible. It equates to 48 samples left-right interleaved in a stereo stream. By the way, AES67 goes on to specify some additional packet structures that could be used because there is no one right answer for the ideal structure. The problem is that larger packet structures are more efficient for the network infrastructure because fewer packets are needed to stream, but larger packets induce greater latency because it takes longer to fill a big packet with 48K audio data samples than a small one. In fact, this is why the WheatNet-IP audio network uses gigabit Ethernet connections and ¼ msec packet timing as our default to keep latency to a minimum. BLADEs don’t have a problem with this because they receive and decode packets directly in hardware without going through the CPU. We use much larger 5 msec packets for streams that come from or go to PCs, which have much higher built-in latency and might get really congested trying to process lots and lots of little packets. One size does not fit all applications but by publishing a standard somewhat in the middle, AES67 provides a common ground for interoperability.
Plus, Stream Configuration
AoIP systems that are meant to be complete audio routing systems frequently need to send the same stream to a number of different destinations simultaneously. Think of all the places your on-air program feed goes to. In AoIP systems and as specified in AES67, streams that are intended to be sent to more than one device take advantage of a standard IP mechanism, multicasting, to maximize network efficiency while avoiding congestion. Since multicast streams can arbitrarily have a wide range of multicast stream addresses, the standard assures that there is a common address range to be used so as to facilitate interoperability.
Likewise, it is desirable to forward the stream payload data (in this case the audio samples) directly to the AoIP stream playback application. Of course historically, different vendors have chosen their own ports to use: AES67 specifies a standard port, 5004, that all devices should be capable of using.
Since AoIP systems were already using standard IP protocols (RTP, IGMP, etc), by providing these specific configuration details for the streams, AES67 makes it possible for devices that adhere to these details to stream audio between them.
AES67 will no doubt be a part of every major studio that includes audio. For five key findings on implementing AES67, see “Commissioning AES67 in Your Plant.”
The One That Got Away
A quick shout out to Jack Cosgrove, who retired this month after 20 years with Wheatstone. Jack was our go-to repair technician for all things Wheat, although some of you might remember him as Arthur Carlson in our WKRP Thanksgiving redux, Turkey Drop from 2016 (see video at bottom of page).
He has been an important part of our support team for the past two decades – a support team that includes long-time Wheaty technicians Jeff Vance, Dick Webb and Buddy Westphal.
Virtually every Wheatstone product ever manufactured is still supported in our factory in New Bern, NC. Jack has worked on every console, network unit, audio processor and equalizer ever designed by Wheatstone – except one! (You can read about Jack Cosgrove and the elusive 8X in Wheat News article Wheat Support to Parts Unknown).
We’ll miss seeing him at his bench every day!
Q: What is the main advantage of an IP audio console?
A: In a word, access. With all I/O managed through the IP network, the IP audio console has no limitations with fixed connection points on the console chassis itself. In the case of our IP-64, Dimension Three and other IP audio consoles, any channel can connect to any audio source, using any preferred audio format at any time, whether it’s HD/SDI, AES, MADI, AoIP, analog or TDM. But that’s just the half of it because an IP audio console also gives you access and control over devices and studios in the network – or outside the studio, as is the case for live remote and REMI applications. That is, you can set up mix-minuses in a flash for a last-minute remote and make rapid route changes using salvos and presets to instantly change audio, mic control, and tallies between sets. In the case of a WheatNet-IP console, you get access to not only all sources at once, but also the presets and any associated logic that go along with each feed for controlling such things as mic ON/OFF, or for changing remote mic settings for IFB, processing and other parameters. And because all of that is at the beck and call of the IP audio console, that surface itself is much more streamlined and intuitively laid out with the controls and functions you need when and where you need them. One nice bonus is that these consoles also tend to have touchscreen interfaces that make them so much easier and intuitive to navigate.
FREE E-BOOK: IP AUDIO FOR TV PRODUCTION AND BEYOND
Putting together a new studio? Updating an existing studio?
We've put together this IP Audio for TV Production and Beyond e-book with fresh info and some of the articles that we've authored for our website, white papers, and news that dives into some of the cool stuff you can do with a modern AoIP network like Wheatstone's WheatNet-IP. And it's FREE to download!
Just click on the cover
Wheatstone was at the NAB New York show and we have the video to prove it.
Richard Lawn from Pro AVL Central and our Phil Owens are shown here sharing the screen with our IP-64 audio console and WheatNet-IP audio networking units.
Our Annual Thanksgiving Video
This video has become a perennial favorite. Scott Johnson's take off on the famous WKRP video. Particularly poignant this year, as Jack Cosgrove (who reprises Mr. Carlson's role) has recently retired (see story above).
Got feedback or questions? Click my name below to send us an e-mail. You can also use the links at the top or bottom of the page to follow us on popular social networking sites and the tabs will take you to our most often visited pages.