<p dir="ltr">Is 1722.1 of any use for this?</p>
<p dir="ltr"><a href="http://standards.ieee.org/findstds/standard/1722.1-2013.html">http://standards.ieee.org/findstds/standard/1722.1-2013.html</a></p>
<div class="gmail_quote">On Feb 27, 2015 9:02 PM, "Len Ovens" <<a href="mailto:len@ovenwerks.net">len@ovenwerks.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 27 Feb 2015, Frederick Gleason wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Feb 27, 2015, at 18:04 06, Len Ovens <<a href="mailto:len@ovenwerks.net" target="_blank">len@ovenwerks.net</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br>
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.<br>
</blockquote>
<br>
I had heard this too. I think this is because:<br>
A) Those who have anything worth while wish to continue to use it as a selling point.<br>
B) Some parties wanted more than others felt was needed.<br>
<br>
Of course it could just be that were lawyers involved... or worse accountants.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br>
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.<br>
<br>
I am thinking a standard that comes with open libraries might make using OCA easier than making a web interface.<br>
<br>
But then, what do I know :)<br>
<br>
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.<br>
<br>
So I think this is needed but rather than come up with something new, this looks like a framework I could use.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Some other AoIP things might be better)<br>
</blockquote>
<br>
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).<br>
</blockquote>
<br>
Looking at:<br>
<a href="http://www.telosalliance.com/support/Livewire-and-RAVENNA" target="_blank">http://www.telosalliance.com/<u></u>support/Livewire-and-RAVENNA</a><br>
The words:<br>
"Does this mean Livewire is going away?<br>
<br>
No! Think of this new RAVENNA broadcast protocol as Livewire 2.0."<br>
<br>
It looks like the new livewire is Ravenna. Though they may just be talking audio transport, control might be a different matter.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So along the way I stumbled on OCA. This is not another OSC, though it could do that job too.<br>
</blockquote>
<br>
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.<br>
</blockquote>
<br>
That too is possible. Even 800 pound gorillas like candy.<br>
<br>
--<br>
Len Ovens<br>
<a href="http://www.ovenwerks.net" target="_blank">www.ovenwerks.net</a><br>
<br>_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br>
<br></blockquote></div>