AES67: Are Two Ships Passing In The Night?

“Ships that pass in the night, and speak each other in passing,
Only a signal shown and a distant voice in the darkness…”
— Henry Wadsworth Longfellow, Tales of a Wayside Inn

A funny thing happened on the way to IP audio interoperability. The Audio Engineering Society committee that developed the AES67 standard for IP audio couldn’t agree on a discovery mechanism, so it included four optional methods, says Aidan Williams, CTO of Audinate, developer of the Dante networking tech used by more than 200 OEMs in products for the professional audio and broadcast markets.

Just to review, AES67 is supposed to provide a way for audio equipment with an IP connection from one manufacturer to hook up to a piece of IP-enabled audio gear from another and communicate.

At a very basic level, before that sort of IP communications can happen, each device needs to know what it’s connected to — a process known as system discovery.

In a pure sense, AES67 provides for interoperability because all a user or vendor has to know is which system discovery options manufacturers have chosen, write some custom code to translate between the different discovery options in use and voila, the devices can communicate.

But in practical terms, this misses the mark, says Williams, because most people think all they have to do is connect two AES67-enabled devices — regardless of which vendors make them — and things will just work.

Few users signed on to begin coding, especially to enable a function that’s so essential to interoperability — the raison d’etre for AES67 in the first place.

Aidan Williams, CTO of Audinate, is calling for vendors to settle on one discovery mechanism for the AES67 standard.

Aidan Williams, CTO of Audinate, is calling for vendors to settle on one discovery mechanism for the AES67 standard.

In this interview with Williams, we discuss the state of AES67 system discovery, which he describes as being like “ships in the night.”

Understand, Williams and Audinate have settled on one of the four discovery options specified in AES67 and would like to see the whole industry do the same. Other vendors selecting other discovery options undoubtedly would like to see the industry support their selections.

This interview isn’t intended to give Audinate a platform to tout its choice. Rather, I thought it made sense to speak with Williams to shed light on the problem.

If AES67 is to live up to expectation, the de facto lack of interoperability caused by having four optional discovery mechanisms must be resolved.

What was your involvement with the development of AES67?
My development work on that standard was in the Internet Engineering Task Force. I spent my time in the Internet standards body rather than in the audio engineering standards body. Those Internet standards then became a part of AES67.

Where do things stand with AES67 implementation with Audinate?
We have a new release of firmware out now with our OEMs, and as they have begun to test AES67 implementations, it has become very apparent that there is a customer expectation for AES67 that you will plug it in, you will turn it on and things will discover each other and that it will just work.

I think people have this expectation that it will be pretty much the same way that Dante works today. The reality of that is that at the moment that doesn’t actually work.

Why?
The reason behind it is that the in the AES67 standard itself doesn’t actually mandate a particular discovery mechanism.

There are four different discovery mechanisms that are listed in the standard, but it doesn’t say: “If you implement AES67, you have to implement this one common discovery method.”

What is happening in our experience is that we’ve got some 200 manufacturers who have Dante products in the market, and so as we push out our AES67 firmware to manufacturers they go and test it with someone else’s AES67 implementation. They are finding that Flap A does not connect to Slot B properly.

Then we get these guys calling us saying, “Wait, this is broken. It doesn’t work.”

And the reason it doesn’t work is because one manufacturer has picked Option No. 3 of the discovery mechanisms listed in the AES67 standard, and another manufacturer is using Option No. 2, and they don’t see each other.

They are like ships in the night. They don’t discover each other on the network.

How did this situation of four different discovery options happen?
I think this turns out to be the practicality of standards making. Sometimes the sausage gets made, and you don’t want to know what is inside of it. And sometimes the sausage doesn’t quite get made.

This is an example of where people agreed on the basic interconnectivity. So they agreed on the basic transport and the synchronization and everything else.

But when you start to move a little bit higher than that, you start to move into discovery and system management –you go up the stack a bit more- it becomes harder to achieve agreement.

So what happened is several of the various companies involved in the Audio Engineering Society had their own solution, which they offered to the standards committee.

Basically company A offers solution A that they invented. Company B offers solution B that they invented. Other people offer standards-based solutions and the committee can’t agree.

The situation Audinate finds itself in is we don’t want to have to implement many different discovery schemes in order to have an interoperable AES67 solution.

So how has Audinate approached trying to get out of this quagmire?
We have a solution in the market, and we want people to understand what’s needed here is for the industry to agree on a single discovery mechanism. We feel in our implementation that we have made a good choice because our discovery mechanism is the only mature Internet standard.

There are four options. Only one of them is a published, mature IETF [Internet Engineering Task Force] standard.

Two of them are company-specific solutions, and one of them is just a draft standard that has never been completed.

One of the things we would like to do is encourage other manufacturers to coalesce around one discovery solution so that AES67 can actually achieve what customers expect of an audio networking solution.

But also we want end users to understand what is going on here so we don’t get blow-back because when that AES67 implementation has to talk to an implementation from WheatNet, Ravenna, from QSC, then that won’t work unless we agree on a discovery solution.

 

 

 

 

2 thoughts on “AES67: Are Two Ships Passing In The Night?

  1. Rod Montgomery

    Has Audinate offered this discovery mechanism on a royalty free basis? The article makes it seem as if there’s no reason to consider coalescing around one of the other discovery options. I like and use Dante, but I’d migrate to something else if it offers practical interoperability.

    Reply
    1. Aidan Williams

      Hi Rod,

      The article doesn’t say so explicitly, but the discovery protocol Audinate has implemented for use with AES67 is SAP, an IETF standard which has been around for a long time. SAP is a very simple standard and I’m not aware of any intellectual property rights associated with it – so there is nothing to licence. When you look at the alternatives listed in the AES67 spec, it is pretty much the obvious choice.

      btw, the Dante firmware release mentioned in the article includes support for AES67 audio transport but remains compatible with all other Dante equipment on the market. You can think of it as being bi-lingual – the firmware can speak both transports.

      – aidan

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *