[LAD] More thoughts on AES67

Len Ovens len at ovenwerks.net
Sat Oct 4 18:54:23 UTC 2014


Having read the AES67 spec, and reading all the various takes on it... I 
have seen this thought a few times:

"AES67 is a good start in that it provides for a common timing method to 
rate-lock everything on the network, but it does not announce the streams 
or provide a common control protocol." [1]

Dispite the quote above, it seems all IF makers do have an open control 
protocol called HTML. That is all of them seem to have web control 
interface as a method of control as well as any other network control. 
This is not the same as interoperability, but it does mean one app could 
control more than one device even though different protocols. 
Discoverability is also less of an issue than it is made out to be because 
of the multicast nature of thiings. The audio packets are reconizable both 
by the addressing as well as content and with the html control open, the 
session parameters are also a known factor.

I have also seen this thought from every manufacture or AoIP protocol 
vendor:

We welcome an open standard and want to support it. Interoperability is 
good for us. (my paraphrase)

I would suggest that no-one wants to be the maker whos stuff works with 
other products, but requires extra attention to get set up. This means 
extra support which costs money. The aes67 document does suggest some of 
the discovery types available:

Bonjour
SAP
Axia Discovery Protocol
Wheatstone WheatnetIP Discovery Protocol

Of these 4 SAP seems to be the one not attached to someone. (it is quite 
old as these things go) But all of them seem to be at least somewhat open. 
That is, I suspect that these were the choices put up but there was no 
agreement. It would not be hard to support all four, but I suspect one of 
them will just get used and become standard. Any forum messages I have 
read just suggest the dev use SAP as happens.

In any case the format of the session information is in the standard, so 
once it is found it can be used.

As for control, the web interface may become more standard (if it isn't 
already, these protocols seem to come with the firmware). Http does not 
only mean human interface.

I think in the same way that these people got together for a common 
protocol, a common control and announce standard will show up.

Anyway, it is probably worthwhile creating an AES67 driver for Linux as it 
would obviously allow the use of the next batch of audio interfaces to 
show up. Even if the user has to use a browser to set the inteface up and 
enter the session parameters, this is still better than the control Linux 
drivers have over some of the audio interfaces that are "supported" in 
ALSA now. The use of the IF DSP power, mixing, eq, etc. may not effect the 
the DAW use so much (though I think it will), but it may suggest new uses 
for the interface.

[1] 
http://www.c2meworld.com/creation/new-protocols-enhance-console-networking/


--
Len Ovens
www.ovenwerks.net



More information about the Linux-audio-dev mailing list