Digital audio routing, switching and control have grown dramatically in broadcast facilities. TDM-based (time-division multiplex) systems were the first to appear in the 1990s. But in recent years, audio-over-IP, or AoIP, systems have gained widespread popularity.
Unfortunately, all these systems use unique protocol features and proprietary components, making interoperability among the different platforms and brands difficult, if not impossible. As Radio World reported in its Aug. 1 issue, the Audio Engineering Society is stepping up to tackle the challenge of standardization so that interoperability might be achieved.
The AES Standards Committee has initiated a project called AES-X192, with the goal of developing a high-performance streaming audio-over-IP interoperability standard. The issues involved are reminiscent of when AES became involved in the serial digital audio standards setting process that eventually produced AES3 (AES/EBU) in 1985.
AES-X192 was conceived two years ago and is being led by Kevin Gross, a media network consultant with AVA Networks, which developed the CobraNet standard. About 100 members including most of the major console and router manufacturers are taking part in this project.
Radio World Technical Advisor Tom McGinley interviewed Gross via email to glean more background and how the effort is progressing.
Kevin Gross
Kevin, you’ve been interested in this topic for a number of years and now have the AES involved pushing for a formal new AES industry standard for interoperability. Tell us about your background and current work as a media consultant, and how X192 got started.
I’ve been working in audio networking since the mid-1990s when we came up with CobraNet at Peak Audio. CobraNet is now owned by Cirrus Logic, and I’m no longer involved with it. I have continued as an independent consultant helping end users, system designers and equipment manufacturers with media and networking technology. In this role, I keep abreast of the IT industry in general and media networking specifically.
From that position, I noticed two things. First, the IT industry has been rallying around the Internet Protocol (IP) as a framework for all things networking. Second, there has been an emergence of a new generation of media networking protocols. Unlike previous generations, the protocols in this new generation use similar technical concepts and standards. Like previous generations, these new protocols do not interoperate.
I recognized an interoperability opportunity between these technically similar protocols and approached the AES with the idea of developing an interoperability standard.
Describe how the AES Standards Committee approaches and conducts the standards setting process.
Standards development at the AES is conducted in a very open manner. Membership in task groups that develop standards is open to any “materially affected individual.” This basically means that standards are developed by individuals, not companies, and the participants have a stake in the outcome. The task groups are given great autonomy in how they choose to organize themselves and conduct business. This autonomy and openness has allowed for quick progress on X192.
What is the proposed schedule for meetings of the X192 group and when do you estimate that a new standard could likely be finalized and emerge for the pro audio and broadcast industry?
We have a draft standard and have been holding teleconferences twice a month to edit that to everyone’s satisfaction. We are nearing the end of that process and are working to have a final draft approved by the task group later this year. There are several further AES approval steps beyond that before it is published as a standard. “X192” is the AES designation for the project. The X192 work product will be published as an AES standard named AESxx, where xx is some number to be determined.
Telos/Axia got the AoIP ball rolling first for console and routing systems. Other manufacturers like Wheatstone and Logitek are now offering their own AoIP solutions. Briefly explain the major similarities and the differences within the various AoIP platforms.
Here’s a summary at right of AoIP protocols from the Objectives and Benefits document you can download from www.x192.org [find the direct URL at radioworld.com/links title=”radioworld.com/links” target=”_blank”]. The similarities are use of User Datagram Protocol or Real-time Transport Protocol for transport and IEEE 1588 for synchronization. But it is possible for two systems to use the same protocol in different, non-interoperable ways. The other differences are in management protocols used for discovering other devices on a network and setting up a connection.
TechnologyPurveyorDate IntroducedSynchronizationTransportRavennaALC NetworXIn developmentIEEE 1588-2008RTPAVBIEEE, AVnu2011IEEE 1588-2008 advanced profile (IEEE 802.1AS)Ethernet, RTPQ-LANQSC Audio2009IEEE 1588-2002UDPN/ACIPEBU2007Data packet arrival timesRTPDanteAudinate2006IEEE 1588-2002UDPWheatnet-IPWheatstone2005ProprietaryRTPLiveWireTelos/Axia2004ProprietaryRTP Table 1: Summary of AoIP Protocols
U.S. broadcasters are familiar with Telos/Axia and Wheatstone, but the others listed on your chart are less familiar to many of us. Can you tell us a little more about those?
Ravenna is most well known in the broadcast industry in Europe. It is a technology developed by one of the Lawo companies, but available to other manufacturers for a reasonable fee.
AVB is a set of IEEE standards jointly developed by the pro audio and networking industries. The automotive industry is now also contributing to development. Special AVB network equipment is required to make this work.
Q-LAN is the networking piece of QSC’s integrated Q-Sys signal processing and distribution system. This is currently used mostly in commercial audio systems though there are some prominent broadcast applications (e.g., U.S. Senate recording studio)
Dante was developed by a network startup in Australia. The technology is licensed to audio equipment manufacturers. Dante is most commonly found in commercial and live applications.
To what extent will details of the proprietary features have to be revealed for AES to be successful in crafting a new standard with X192?
One of the ground rules we’ve used in X192 development is to reference existing standards wherever possible, rather than invent new techniques and protocols. I believe this approach reduces exposure to intellectual property issues. You never eliminate the risk entirely, however.
Broadcast engineers have hoped that generic, off-the-shelf Ethernet switches could be employed in AoIP systems. However the switches now being used have to be qualified, managed switches and how they are configured is critical. Why is this issue of switch implementation so fussy and confusing?
An important piece of a successful AoIP system is network quality of service features. QoS standards and technology have existed in the network world for years but have not, until now, been given a real workout. Network vendors are learning from fussiness experienced by their customers and the situation is rapidly improving. Anyone building an AVB switch has to explicitly deal with these issues, for instance.
I was involved in the development of early systems for recording direct to hard disks. That was also initially quite fussy. Media networking feels like it is on a similar technology curve. We’re not going to remember any of this in a few short years.
In some cases, only a specific manufacturer’s switch is compatible. Won’t there need to be some kind of standardization of switch architecture, firmware and programming established as part of any X192 standard?
One of the stated goals of X192 is to work with standard IP network equipment. I have tested a fair amount of network equipment for QSC, and my general findings are that some of the equipment (even otherwise high-performance equipment) does not give the real-time performance or offer some of the QoS features required by real-time media networking. As I say, this situation is improving quickly.
Is it realistic to expect that after an AES-X192 standard is established, engineers might eventually be able to buy a generic $50 switch from Best Buy and run a multi-studio broadcast facility through it?
If you’re going to build a small audio-only network, we’re already there. Surprisingly, the cheap switches often have the best raw performance. That’s because everything is done on one IC. Things have to slow down to go between ICs in the larger and more complicated equipment. If you want to mix audio with other IT functions, you will need QoS and that generally requires a managed switch. Fortunately, almost all gigabit switches you can buy today are managed and have the QoS features. They’re not exactly $50, but the Cisco Small Business switches, for instance, get the job done for less than $1,000.
Most of the U.S.-based AoIP systems use the same Cisco or HP Ethernet managed switch models. What other switches are being used?
Just about anyone who builds a gigabit Ethernet switch has a switch that has the required QoS feature set. Examples can be found from all these manufacturers:Dell, Cisco Small Business (formerly Linksys) Extreme Networks, Juniper, Brocade, Netgear, 3Com, Alaxala, Allied Telesys, Avaya, Moxa and Hirshmann.
Beyond the IP network itself, the other major hardware link of any AoIP system is how source devices get connected to the network. To what extent will X192 set any protocols or rules for these components in the new standard?
X192 describes how audio data is formatted into network packets and how everything is synchronized. Additionally, X192 specifies protocols that allow devices to find one another on the network and then exchange commands to set up the aforementioned audio transmissions across the network.
Other aspects of configuring these boxes such as preamp gain settings, logic inputs and contact closure outputs are outside the scope of X192.
I don’t know whether X192 makes these network interface products commodity items. I don’t think it is a question of great import because where I see the real value of interoperability is where, instead of using a second piece of gear to interface a product to the network, the network interface is built into audio products such as automation equipment, processors, consoles, amplifiers, microphones, speakers and transmitters.
Synchronization is a vital element within AoIP. Some systems are using the IEEE 1588-2002/8 standard while others are proprietary. Will X192 likely specify the IEEE standard?
Standards development rules of participation discourage me from confirming or denying this to the press, but, yes, it is very likely. 🙂
Aside from the hardware, what other factors and considerations within an AoIP system complicate the goal of forging an interoperable standard?
I think business issues are really the important complicating factors. There are business models out there that rely on proprietary systems. I think many of these would work better for everyone if opened up, but that can be a scary transition to make.
Axia/Livewire is collaborating with Lawo/Ravenna from Germany and appears to be leading the effort to leverage an open standards approach for AoIP interoperability. Axia’s Mike Dosch has even said that he would expect any AES-X192 standard to look very much like “the new Livewire.” What is your position on this development and how might it affect the X192 process?
Axia and ALC (Lawo/Ravenna) have been very active in the development of X192. It is clear to me that open interoperability is a business priority for both of them. With X192 we’re going to make interoperability available to the industry. Anyone who sees the value in it can pick it up and run with it. We appear to have a game going with Axia and ALC even before the standard has been finished. To me, that’s a good sign that X192 will achieve the critical mass of acceptance required to make real and useful interoperability.
Compared to the AES3 standard setting process and result, what similarities and differences do you see with the X192 process as it proceeds?
AES3 was first published in 1985, so I can’t make a first-hand comparison. I have encountered some sour attitudes about the standards process and results. What is important to understand about AES standards is that there’s a lot of autonomy given to the individual groups developing standards, and so there’s no single process. Because of the generosity of my sponsors, Axia and QSC, I’m able to devote a significant amount of my time leading the effort, researching basic technology, drafting the standard and interfacing with related standards bodies. I believe this level of attention has helped move things forward relatively quickly.
While full interoperability of the major systems and protocols would be an ideal goal of X192 as a new AES standard, in the end it may come up short of establishing or requiring that for all participating systems and specific protocols. Expand on that as a possible outcome.
I think what you’re getting at is described here [see comic below]. I’m not going to claim that I have a surefire way around this pitfall, but we are not trying to solve everyone’s problems with X192. Full interoperability is not the goal. We’re trying to define a fairly basic interoperability mode. We expect manufacturers to go beyond that and develop their own extensions. If X192 is successful, maybe we’ll have the opportunity go back and standardize some of those extensions.
credit: Courtesy xkcd.com
What major players have not yet stepped up to be part of the X192 effort?
There are over 100 individual members of the task group. Members come from networking, silicon, broadcast, live sound, commercial audio, music production and other fields. End users, system designers, integrators and equipment manufacturers are represented. X192 is a technical effort, but there has not been a lot of publicity yet (publicity doesn’t usually help get technical work done), so I’m sure there are some that are simply not aware of the initiative.
Is there the expectation that similar to AES serial, there will be two standards developed … one high-performance interface for pro audio and a cheaper one for consumer systems?
We’re including in the standard several options in terms of latency, bit resolution and sample rate. It is not feasible to require all devices to implement all modes so I expect AoIP products will self-classify themselves in the market based on the capabilities they implement. Because of the protocols we’re using, X192 will have a certain amount of intrinsic interoperability with VoIP systems. A VoIP device could be dialed up to minimally support X192.
Tom McGinley is technical advisor and longtime contributor to Radio World.
Comment on this or any article. Write to [email protected], attention Letter to the Editor.
