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
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
