28 Feb
2015
28 Feb
'15
6:02 a.m.
On Fri, 27 Feb 2015, Frederick Gleason wrote:
Looking at:
http://www.telosalliance.com/support/Livewire-and-RAVENNA
The words:
"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.
That too is possible. Even 800 pound gorillas like candy.
--
Len Ovens
www.ovenwerks.net
On Feb 27, 2015, at 18:04 06, Len Ovens
<len(a)ovenwerks.net> wrote:
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
selling point.
B) Some parties wanted more than others felt was needed.
Of course it could just be that were lawyers involved... or worse
accountants.
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. 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). So along the
way I stumbled on OCA. This is not another OSC, though it
could do 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.