Hardware Infrastructure Global Viewpoint – March 2016

Does Broadcast Need Another Audio-Over-IP Standard (AES70-Part 1)?

The new open control and monitoring standard for professional audio and AV media network devices was officially standardized in January by the AES and published as “AES70-1-2015 standard for audio applications of networks – Open Control Architecture-Part 1." Should we care?

The AES version was based and developed from an already-tested specification from the Open Control Architecture  Alliance (OCA). The association membership includes manufacturers of both large and small-scale audio networking products. These vendors wanted to be able to build solutions with a common and open media networking system control standard. Many of these vendors have already produced an array of products using the OCA standard, so the AES70 version is already product tested.

AES67 and AES70

AES70 is essentially the same as OCA 1.3, the specifications for which have been available on the OCA Alliance website since October 2014. It is that standard that many OCA members already have implemented in their products. However, despite its increasing popularity with the building and home automation industries, it has yet to see wide-spread penetration into broadcast and production spaces. In reality, some wonder about the need for another audio IP standard.

The AES67 standard does provide synchronization, transport and basic connectivity functions. But AES67 does not address device control and discovery. Said Andreas Hildebrand, Senior Product Manager at ALC NetworX GmbH,  (Ravenna technology) “AES70 is an independent, yet potentially complementary, standard covering device configuration and control, stream configuration and routing management, and elementary device and service discovery."

Hildebrand suggests that AES67 has been successful in part because of its restriction to only the absolutely necessary definitions of audio over IP and that helps reduce implementation complexity. The AES67 standard does have the ability to provide some basic command and control functions, but AES70 expands such capability to a much greater degree.

Maybe not needed now

Some audio experts suggest that while audio over IP is well established, markets needs differ. The type of control functions needed in a large building to support audio, PA, background music and emergency communication are far different from that required for broadcast and production audio. In addition, the broadcast and production market already has multiple IP audio networking options so these users may not see value in rushing to add AES70 functionality to their facilities.

For instance, two intercom manufacturers, Riedel and Clear-Com indicate they plan to watch the development of AES70, but neither have announced NAB 2016 show products with such capability. Simon Browne of Clear-Com said his company was well aware of OCA and as it matured it would be a technology in which his company would look to participate. The question remains, will NAB 2016 show attendees see AES70-enabled products at this year’s exhibition? Or, should engineers wait for Part 2?

Your thoughts?

_________________________________________________________________________________________

Reader comments:

I read your Audio Global Viewpoint article about OCA / AES70 with much interest.

I was on the committee that created AES67, and was an original inventor of AoIP itself, back 16-17 years ago or so, here at Telos. Our Livewire technology is regarded as the first true AoIP solution, and is at the heart of 7000+ live on air radio studios globally today.

I've been at arm's length watching the progress of the AES70 development with interest as well. (No one can be be on all of the committee's!) 

I would wish that the reading audience would be made more aware of the clear delineation of the intentions behind and between AES67 and AES70. What was written seemed to somewhat blur the line between the two, and then ask the questions, do we care, and is 'another' standard needed now?

These are for sure good questions, and always relevant to ask, don't get me wrong. I would say, however, that there is a clear answer: 

AES67 is specifically for the intent of making audio over IP connections. The equivalent of an 'audio cable', but using the IP network.

AES70 is specifically for the ability to have vendor independent control of audio equipment that did not exist in any prior existing audio over IP solution.

AES70 is not really tied in any way to AES67, or in particular limited to use with Audio over IP.

Just as you correctly show in your Venn diagram, you list "analog cable". If I happened to have a piece of audio gear with analog audio interfaces, and that gear had an ethernet port for control, AES70 could potentially be used for that control (gain changes, filter switching, mixer controls, etc etc).

(It is kind of a stretch to say that AES67 has some basic command and control functions. AES67 allows you make and break audio connections. Kind of the equivalent of plugging and unplugging an audio cable. In some really narrow way, maybe that could be called 'command and control', but its not really so much. The intent of command and control of audio equipment is not within AES67.)

The one statement from the article that jumps out at me as being counter informative is: "In addition, the broadcast and production market already has multiple IP audio networking options so these users may not see value in rushing to add AES70 functionality to their facilities."

AES70 is bringing something unique to the party that the multiple existing IP audio networking options don't: The ability to have vendor independent control of audio equipment.

So the two are really apples and oranges, and in the blizzard of buzzwords, admittedly it  is a challenge for the user community to make heads or tails out of all the names and acronyms. That's why not lumping AES67 and AES70 together in any way probably better serves understanding what they are each for.

Now, the rest of your assertions are fair: how does a vendor know when it is the right time to jump into supporting a new standard... This is always high on the list for technical and marketing directors to consider. But the first step is clarity of understanding what a new standard is intended for, to make the clearest case for its value proposition.

Best Regards,

Greg Shay, CSO, The Telos Alliance

Let us know what you think…

Log-in or Register for free to post comments…