Len Ovens len at ovenwerks.net
Sat Feb 28 05:00:29 UTC 2015

On Fri, 27 Feb 2015, Frederick Gleason wrote:

> On Feb 27, 2015, at 18:04 06, Len Ovens <len at 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 
selling point.
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).

Looking at:
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.

>> 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.

That too is possible. Even 800 pound gorillas like candy.

Len Ovens

More information about the Linux-audio-dev mailing list