On Fri, 27 Feb 2015, Frederick Gleason wrote:
On Feb 27, 2015, at 18:04 06, Len Ovens <len(a)ovenwerks.net> wrote:
Some background: I have been looking at AoIP and reading what I could.
AES67 has the biggest complaint that it has poor
service discovery (well
none actually). I have been reading product manuals for various AoIP
formats and what I have found is that some of the other ones do not have
very good/any discovery either. I do not know if this is the protocols
fault of the product but the setup for a Ravenna AoIP DAC/ADC box to a
Ravenna PCIe card requires the user to know what the IP for both units are
and then log in to both units via HTTP(s) to set them up in some sort of
static configuration. This sounds no better than raw AES67.
I had a discussion about this with one of the high-level execs from LWRO
at last year’s NAB show, and he pretty much admitted that service discovery
had been intentionally left out of AES67 because the vendors couldn’t
(wouldn’t?) agree on a uniform approach.
I had heard this too. I think this is because:
A) Those who have anything worth while wish to continue to use it as a
B) Some parties wanted more than others felt was needed.
Of course it could just be that were lawyers involved... or worse
As for Ravenna, you’re quite right — service discovery is not covered
anywhere in that spec either (beyond some very
weak genuflections towards
Zeroconf discovery). It’s left as a vendor-defined detail.
Zeroconf discovery is not that helpful on it's own as I found when I
started playing with Avahi. It can tell you where a device is and if that
device is multicasting a stream, tell you the address and spec of the
stream. Control functions seem to be left to http browser setups. These
would be whatever the manufacture decides to set up. What the manufacture
decides to set up most often goes like "oh by the way we need a web
interface to control this thing, throw one in". Meaning that not only are
they all different, but they are not even different on purpose... just
everyone redoing the same work.
I am thinking a standard that comes with open libraries might make using
OCA easier than making a web interface.
But then, what do I know :)
My real thought though, is that this could be useful in Linux if the rest
of the world follows or not. In fact getting a lib that is cross platform
(mainly OSx) might have some impact too. But I think a lot of the
experimental music/audio is a Linux thing and in those kinds of worlds easy
hook up and control is important to the artist's experience/art.
So I think this is needed but rather than come up with something new, this
looks like a framework I could use.
(Some other AoIP things might be better)
LiveWire is considerably better, where there is a full multicast-enabled
discovery mechanism along with such niceties as network-transparent GPIO.
The problem, of course, is that none of that is openly documented at the
protocol level (although Axia has been slowly moving in that direction over
the past couple of years).
"Does this mean Livewire is going away?
No! Think of this new RAVENNA broadcast protocol as Livewire 2.0."
It looks like the new livewire is Ravenna. Though they may just be talking
audio transport, control might be a different matter.
So along the way I stumbled on OCA. This is not another OSC, though it
that job too.
The problem I have with this is that it’s just too late in the AoIP game
for it to make any real difference. LiveWire and Ravenna are the two 800
pound gorillas in this space; any of the other AoIP systems are just niche
players at this point (at least in the pro audio/broadcasting space).
Anything that doesn’t have the blessing of Axia or LWRO (preferably both)
doesn’t stand a chance of getting any traction in the market.
That too is possible. Even 800 pound gorillas like candy.
Linux-audio-dev mailing list