4 Oct
2014
4 Oct
'14
8:55 p.m.
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
5 Oct
5 Oct
12:38 a.m.
On Sat, 4 Oct 2014, Len Ovens wrote:
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
It could also be that makers would like to offer the in house networking
variety as well as the one universal one instead of offering 5 or 6
different IF cards as some do now.
--
Len Ovens
www.ovenwerks.net
6 Oct
6 Oct
7:31 a.m.
On Saturday, October 04, 2014 03:37:10 PM Len Ovens wrote:
On Sat, 4 Oct 2014, Len Ovens wrote:
You have to remember that many of these vendors have carved out their own
little fiefdoms within AoIP. Many of them have a primary focus: live audio,
broadcast, distributed PA, telephony/VOIP etc. The only real way to integrate
them in large facilities without a common format is to have analog endpoints
that patch the separate types of systems together. That saves money, so when
contractors are putting together bids, and there are vendors that support a
cheap way to integrate layer 3 protocols, they will get advantage over the
ones that don't.
The AES67 looks to provide gateway nodes for the various systems. It has some
inherent limitations, but for for the scope of Linux Audio I think it will be
sufficient for what most people would want to do with it.
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
It could also be that makers would like to offer the in house networking
variety as well as the one universal one instead of offering 5 or 6
different IF cards as some do now.
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.
Bonjour is just the apple branding of zeroconf. It's not really attached to
apple. I think it would offer the most robust solution. In my experience SAP is
very slow to propagate. There's also SLP which almost nobody uses anymore. As
well as UPnP / SSDP, which I hate, but would integrate well with HTML based
control messaging.
-Reuben
3:39 p.m.
On Mon, 6 Oct 2014, Reuben Martin wrote:
On Saturday, October 04, 2014 03:37:10 PM Len Ovens
wrote:
The AES67 looks to provide gateway nodes for the various systems. It has some
It sounds like every box will be usable as a gateway and that it would be
possible not to use a gateway but just use the audio where needed.
However, I think you are right that a gateway style of use is what will
happen. Most AoIP boxes that I have read about seem to support many more
streams than they have HW I/O.
inherent limitations, but for for the scope of Linux
Audio I think it will be
sufficient for what most people would want to do with it.
I think the limitations may actually be a good thing for Linux. As with
most things, Linux tends to react to what is out there. AES67 would give
Linux audio a way forward in Audio IF for (semi)pro audio HW. USB has
improved a great deal, but seems to suffer some of it's own limitations.
It seems that Most AoIP boxes will allow working with a web IF to control
all routing, internal dsp, mixing etc. Many of them also seem to deal with
MIDI over IP as a control mechanism too (though the MIDIoIP is not always
anything standard) some of them having MIDI ports just for that.
It is not the perfect solution, but it sounds way better than the current
ALSA solutions where just being able to see the I/O ports means it is
supported. Very few offer even routing.
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
Bonjour is just the apple branding of zeroconf. It's not really attached to
apple. I think it would offer the most robust solution. In my experience SAP is
very slow to propagate. There's also SLP which almost nobody uses anymore. As
well as UPnP / SSDP, which I hate, but would integrate well with HTML based
control messaging. From a Linux POV, using whatever HW someone else has
already built, This
does not matter in the end. Something will end up getting used
and Linux
will have to deal with it at that time. On the other hand, most Linux
studios are small, using an audio IF that isin the same room as the
computer. AoIP will allow having more than one IF in more than one room
and be easy to use in a static manner. That is, it may be a pain to set
up, but once set up, it will just work.
--
Len Ovens
www.ovenwerks.net
4021
days inactive
4023
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
Len Ovens -
Reuben Martin