LOS ANGELES—As computer scientist Andrew S. Tanenbaum noted, somewhat tongue in cheek, in his 1988 book “Computer Networks,” “The nice thing about standards is that you have so many to choose from.”
The computer industry has long since become a multivendor business, enabling consumers to pick and choose components from a variety of brands, safe in the knowledge that they work together. That paradigm will become increasingly valuable to broadcasters, too, as digital audio—and video—networks are increasingly adopted.
Bringing standardization to digital audio networking, the Audio Engineering Society published AES67, which enabled high-performance streaming audio-over-IP interoperability, in September 2013. After three years, are we anywhere nearer to that multivendor paradigm?
“There are a lot of implementations out there,” said Kevin Gross, an independent consultant who led the group that developed and ratified the AES67 standard. For example, he said, Audinate Dante devices now offer AES67 support and QSC very recently announced that its Q-Sys platform will support the standard.
Indeed, the universe of AES67-compliant products has expanded to include equipment from the likes of Wheatstone, Calrec Audio, Lawo, Yamaha and others. Perhaps more importantly for the broadcast industry, video equipment manufacturers are implementing AES67 for audio transport. And within the broadcast video industry, certain standards have been developed that adopt AES67 to handle digital audio, he said, including the Video Services Forum’s TR-03.
SMPTE 2110 intends to codify TR-03 (therefore AES67) and TR-04 audio and video IP transports within that standards body. Standing behind TR-03 is the Alliance for IP Media Solutions (AIMS), a nonprofit alliance promoting the open standards that enable the industry to move from legacy SDI systems to IP-based transports.
“AIMS has done public interoperability demonstrations; there was a big public demonstration of TR-03 technology at IBC,” said Gross. “If you look carefully, the AES was part of that demonstration, as was the Media Networking Alliance, supporting AES67. Any of the audio in those demonstrations was AES67.” There will be another demonstration building upon those previous events at [the 2017 NAB Show], he said.
AES67-2013 was subsequently revised as AES67-2015. “We just clarified some things,” said Gross. “I hope we’ll be able to revise it again in 2017.” He reported that the Task Group is currently developing PICS, (Protocol Implementation Performance Statement). “It’s a big matrix that spells out what pieces of the standard are implemented. This is a mechanism that allows somebody to communicate what options they have included in their implementation.”
The statement will also provide guidelines for testing. “We don’t have a compliance program like the AVnu Alliance does for AVB. Testing must be done by the individual manufacturers, so this will be helpful in improving the quality of implementations,” said Gross. AES published a report in May 2016 on interoperability between AES67, SMPTE 2059-2 and IEEE Std 1588-2008 using Precision Timing Protocol (PTP). “They’re compatible,” said Gross, “so we expect everybody to be able to use a single synchronization system for their audio and video. SMPTE has been doing some interoperability testing that is ongoing.”
The AES has also conducted plugfests between components from different manufacturers. The first was in Munich in 2014, followed by another in Washington, D.C., in 2015. A third will take place at the BBC this month, said Gross, and a report should be published in March that will list the manufacturers, which is expected to include video equipment companies with early implementations of SMPTE 2110, he added.
AES67 describes how audio flows over networks. A related standard, AES70, is about controlling audio devices remotely over networks. “AES67 does not completely specify a standard connection management method, so different manufacturers have started using different methods with the result that, although these devices can potentially exchange audio, they sometimes have trouble doing so because they don’t speak the same language as far as establishing the connection,” commented Jeff Berryman, senior scientist at Bosch Communications.
AES70, the standardized version of Open Control Architecture (OCA), was published in 2015. Berryman chairs the SC-02-12-L Task Group on AES-X210, which was the original project that ratified OCA. “X210 is about to start working on a document to describe how you use AES70 to manage the connections of AES67 networks. It will be an implementation guide,” he said.
The AES67 standard did not mandate discovery or control functions. AES70 rectifies that, providing standardized control management that helps connected devices to establish, and later break, connections and direct the flow of audio around the network. “AES70 can potentially work with a wide variety of media transport protocols, not just AES67,” said Berryman.
AES70 uptake is somewhat slower than for AES67, he reported. “The control problem is a little bit secondary in people’s minds, so AES70 hasn’t had the explosive growth that AES67 has, but it’s coming along steadily.” He expects the connection management aspects of AES70 to be revised this year in a third iteration, to be known as CM3.
The scheme has been championed by the OCA Alliance for a couple of years. “We’re starting to have companies now that are not members of the OCA Alliance doing OCA implementations, which is encouraging,” said Berryman. “We don’t want everybody to feel that they have to join the OCA Alliance to implement AES70; that’s not the point.”
There is an alternative connection management scheme developed by the BBC known as Network Media Open Solution (NMOS) that is supported by Advanced Media Workflow Association (AMWA) in collaboration with AIMS, Berryman noted. “NMOS is far more visible in broadcast than anywhere else. Ravenna—an AES67 implementation—has a version that uses NMOS for connection management.”
Berryman stressed, “AES70 has been designed from the outset to coexist with other connection management solutions. Yes, there will be two standards; and the ability to coexist, which is relatively routine, will be defined by AES70. AES70 has a good way of making devices bilingual.”
Logitek Talks AoIP
TV Technology recently talked with Logitek President Tag Borland about AES67 and athome production capabilities.
TV TECHNOLOGY: How has AES67 affected the design of your current products and how Logitek designs future products?
TAG BORLAND: The AES67 protocol is being designed into all our new products. To fill in the gaps we are in the process of implementing the discovery sections of NMOS.
TVT: Does Logitek participate in the AES67 interoperability “plugfests” to ensure integration with other brands?
TB: We currently do in-house testing against a selection of products from other vendors.
TVT: Will Logitek implement AES70 to offer their users tighter integration with other products?
TB: We already fully support the control interfaces for many switcher and automation systems via IP. Logitek will continue to provide protocols as needed but the complexity of AES70 compared to its perceived benefits may slow adoption.
TVT: Do any of Logitek’s products offer “athome production” capabilities?
TB: Logitek provides an IP-based glass console control system with each Jetstream mix engine. This product allows an operator to use the same features and functions remotely as they can from the hardware control surface. It is also possible to combine faders and control from multiple mixers at multiple sites into a single on-screen experience. The vMix+ design tool allows users to customize default screens for maximum efficiency or to create whole new ones to their own requirements.