Being a sound engineer is not an easy job. There is a lot of responsibility involved. You are not only expected to perform your function seamlessly and professionally, in some cases you may also be expected to know the various intricacies of your craft instinctively, because you are the person behind the board.

Over the past few years, there has been an inescapable shift in the audio realm (and every other realm it seems) towards digital. With this shift comes a much more complex set of terms and concepts to learn as an audio engineer.

For example, operation and control protocols dictate how sound is going to travel along the signal chain. It’s an entirely different animal than when you were dealing with analog signals. As if that in itself weren’t challenging enough to learn!

You may not necessarily have to be completely familiar with every digital audio protocol, but it helps to at least have a cursory understanding of their characteristics.

Audio manufacturers admit that there is a fair amount of confusion out there in regards to this topic. Many folks in the industry actually find the many standards, differentiations and layers of control protocols confusing. That is probably why many of them are working to ensure that we simplify things by grouping together all the best characteristics of dozens of audio protocols into one standard.

Of course, getting there will not be so easy.

A Little History
In the analog days, as the needs and demands of major productions increased, so did the need for multiple cable runs. Sometimes, literally hundreds of channels of audio were needed to accommodate big shows and productions.
Running copper wire for all of these channels was a feat only the biggest, highest budget productions could manage.

Digital allowed for a much easier transport method for the audio, as well as a much higher degree of control. So, as digital products started to come onto the marketplace, protocols needed to be developed in order to handle the signals properly.

“I date the start of professional digital audio transport to 1985 when the Audio Engineering Society (AES) released the two channel AES3 Standard after a development process that involved many manufacturers and other interested parties.” remembers Rayburn. “The European Broadcasting Union (EBU) then released a slightly modified version of this Standard. This is where the AES/EBU nickname came from. The first fully networked professional digital audio transport was CobraNet which was released in 1998 with the first installation being Disney’s Animal Kingdom.”

It seemed as if from there, the race was on.

“DMP7 was our first Digital Mixer, and I believe the industry’s first.” says Kevin Kimmel, Mixer Product Manager for Yamaha Commercial Audio Systems. “It was primarily analog I/O with the exception of a digital cascade port which utilized Yamaha’s proprietary Y2 format – essentially a 32-bit version of AES with a wider voltage characteristic.”

“Digigram was first a CobraNet licensee, and the CobraNet licensing agent for Europe, and then developed their EtherSound technology.” recounts Rayburn. EtherSound came on the scene about 2001.

As time went by, audio manufacturers had to decide which protocol they were going to use to move audio throughout their devices. Or, they were going to have to decide whether it made any sense for them to develop proprietary protocols of their own.

“Audinate, Aviom, CobraNet, Ethersound, Roland [REAC], and Qsys are not standards in the sense of being issued by an International Standards agency such as AES, IEC, or EBU,” Ray Rayburn explains, “Instead they are issued by a firm that designed the scheme, and may in some cases license other firms to make compatible equipment.”

So in all, you have proprietary standards, agency standards and control protocols, all on the scene in a flurry of acronyms. Add to this the many connection types that get grouped into these associations: XLR (standard mic cables), S/PDIF (Sony/Philips Digital Interconnect Format), Toslink, Coaxial, Fiber Optic, IEEE802 (Ethernet), IEEE1394 (FireWire)… needless to say it is easy to get confused.

Digital Audio Protocols- Point to Point, Network and Control
There are dozens of protocols that can push digital audio around, and they come in different forms. For the purposes of simplification, even though there really is nothing simple about this topic, we’re going to split the audio protocols into three groups.

First, you have Point to Point (or peer to peer) protocols. These allow you to send data from one point to another.

Then you have Network protocols, which allow you to send and receive data, as well as have several points of interaction along the way.

Finally we have Control protocols, which refer to the engineer’s ability to control various parts of the system, from console to amplifiers to DSPs to speakers. Control protocols are not necessarily “true audio” protocols because they are designed for a different purpose than moving audio.

“There are two classes of multichannel digital audio transport schemes: point-to-point, and multi-point to multi-point [network].” Ray Rayburn clarifies. “For example AES3 is a point-to-point scheme with just two ends.

There is the signal source end, and the signal destination end. An Ethernet computer network by contrast has multiple points, and any point can originate a signal and send it to any or all of the other points on the network.”

“[Point to point means] that you’ve got something that generates a signal, something that receives a signal and converts it back to analog, or passes it off.” says Jeff Lange. “It’s not really a network like one you would think of in a computer where you can have multiple points putting things in and pulling them off. Aviom’s Pro 64 is a true network protocol, where you put the audio on the network and make it available to many people, or many could put channels into that network.”

To clarify the third group, some manufacturers have developed control protocols in order to manage the various points along a signal chain containing their products. An example of this is HiQnet, by Harman.

“HiQnet is in itself not an audio protocol.” explains Adam Holladay, Senior Market Manager of Harman Professional System Development & Integration Group. “It is an accompaniment to an audio protocol and it is the control element that you need to sit alongside whatever audio protocol you are using, with Harman equipment of course.”

In Harman’s case, they have used Cobranet as their audio protocol of choice for the past ten years. Mr. Holladay explains the difference between an audio protocol and a control protocol by identifying them as separate entities with separate functions.

“Audio protocols as they stand simply transmit audio from A to B, they don’t really allow you to control what’s happening to that audio in any of the devices on their own. Therefore they need that complimentary part from a control perspective. That’s what HiQnet does.”

Other manufacturers have developed their own audio protocols that also allow for control, such as Roland’s REAC (Roland Ethernet Audio Communication).

“REAC is a Roland-developed bi-directional audio protocol that carries 80 channels of audio (40 in each direction) at sampling rates of up to 96kHz and up to 24-bit resolution – all over a single Cat5e cable.” explains John Broadhead, Vice President at Roland Systems Group.

Because of these various selections, and different characteristics of each protocol handling audio in specific ways, some manufacturers developed network cards to enable flexibility in their consoles, so that the end-user could customize their console to use a protocol of choice.

“In our Allen & Heath system, we’ve got what we call a mini-multi digital out card, which is a single card that has all of those protocols on it.” says Gabriel Whyel, Marketing Director, American Music & Sound. “We group together whatever protocols we can, and then when they need to be separated, we separate them.”

Similarly, Yamaha digital consoles are customizable in the sense that they can run various digital audio protocols with the installation of cards, such as Ethersound and Aviom cards.

Can’t We All Get Along?
Amidst all of this accommodation and flexibility, one of the major problems we are faced with in the digital audio world, is that not all of these protocols can work together in a signal chain.

For example, an audio signal would have a hard time going from REAC to Cobranet to A-Net.

“You can’t go directly between [protocols].” Jeff Lange explains. “Although, [Aviom] makes devices that are AES3, which is a digital protocol, that Cobranet also makes devices for, so that you can hand off your audio via a common protocol between the two.”

“Whirlwind makes the PXP: Protocol Exchange Platform that provides direct conversion between any two of the following protocols: CobraNet, Aviom, EtherSound, Dante, or MADI.” Ray Rayburn says. “To convert between other protocols you would need to go to AES3 in the middle.”

Not being able to smoothly transition between protocols makes things complicated for end-users, because they can’t build a system using different protocols without spending a great deal extra on peripheral gear to make everything “get along”.

On the other hand, it is also challenging for manufacturers.

“We suffer as a manufacturer, as all other manufacturers do, in making the choice- do we support one protocol and invest in that one, or do we support all protocols, or a selection of protocols in between?” states Adam Holladay. “We might find that if we offer only Cobranet devices, and yet the House of Worship system may be an Ethersound system, we are automatically not included as a solution for that particular system, because we don’t have a suitable Ethersound product. Vice versa- if another company has Ethersound, but the system is Cobranet, again they are excluded from that choice.”

This is partly the reason why there is such a push to join everything together under one protocol.

Brave New World?
If you haven’t already heard of it, there is a relatively new protocol being discussed right now called AVB (Audio Video Bridging).

What is interesting about this protocol is that it is referred to as an “open standard”. That means in essence, that it can run on an audio system made up of various manufacturers’ components, solving the problem of having to go “all-in” with one manufacturer when building your digital audio system.
It’s also built to carry video at the same time, increasing the scalability factor for many installed systems.

“When Ethernet was conceived, it was enough to transfer data from point A to point B, but there was not fundamental support for the delivery of time sensitive data (i.e. streams of media).” explains Lee Minich, President of Lab X Technologies, LLC, who is a member of the AvNu Alliance- an organization promoting awareness of the benefits of the AVB protocol.

“Instead of trying to work around the limitations of Ethernet,” Minich continues, “the work began in the IEEE (that standardized Ethernet to begin with), to ‘fix’ the problems with existing Ethernet. The primary focus behind AVB is to usher in a new realm of media connectivity to drive costs down, and increase adoption, and enable a wide array of new products in a variety of markets.”

Of course, not everyone is convinced that the transition will be a smooth one.

Part of the problem with an open standard is that there is technically no governing body that would claim responsibility for a component breaking down.
For example, if there is a link in the signal chain that malfunctions, and the signal chain is made up of several different manufacturer’s gear running AVB, the concern is that this will lead to the “blame game”. It would be too easy for any manufacturer to point a finger at another, stating that the problem is in how a different manufacturer’s component is running AVB.
However, the AvNu alliance is confident that things will work out.

“The AVnu Alliance is developing compliance and interoperability tests to certify that AVB devices can be certified and work together.” Minich says. “Similar to debugging a “proprietary” protocol, the ultimate burden comes back to the manufacturer of the equipment incorporating the technology.

However since AVB is a fundamental augmentation to networking infrastructure, there will be a growing number of manufacturers and IT professionals who are trained in such support, just as the IT community is today.”

As far as AVB being the new ‘umbrella’ standard, we are still a ways off.
“Since AVB is an extension of the Ethernet Standard (issued by the IEEE) they first need to finalize AVB, then get the revised IEEE Standard issued, and then get the manufacturers of Ethernet switches to incorporate AVB support in new models of their switches.” Ray Rayburn points out. “Only after switches with AVB support become available, and audio equipment manufacturers add AVB support into their products, will you be able to start building AVB systems. This is getting real close, but we are not quite there yet.”

The Choice is Yours
Even though there are varied selections for audio protocols currently in use, it is important to remember that one is not any better than the other. It depends on what you as an end-user requires out of your system.

“When you’re trying to do a particular job, certain strengths of a protocol might make it win for that application where the next one will not. Doing ‘apples to apples’ comparisons between protocols is a difficult thing to do.” Jeff Lange explains.

The decision should be based on what manufacturer you think does the best job in handling the job you have set out for its products to perform.

“Each scheme has its own unique strengths and weaknesses. Which protocol is best depends on the application.” reiterates Rayburn.

The tried and true methods of selecting an audio system still apply and always will- no matter what protocol is being used. That is: trust your ears, train your operators and do your research. Behind the scenes, talented folks will continue to work towards making the house of worship audio engineer’s job a little easier, at least when it comes to defining digital audio protocols.

Kevin Rogers Cobus is the executive Editor of TFWM. Special thanks to Jeff Lange and Ray Rayburn for their contributions to this article. Additional questions please post on our Facebook wall so we can all learn together.