Is 1722.1 of any use for this? http://standards.ieee.org/findstds/standard/1722.1-2013.html On Feb 27, 2015 9:02 PM, "Len Ovens" <[email protected]> wrote:
> On Fri, 27 Feb 2015, Frederick Gleason wrote: > > On Feb 27, 2015, at 18:04 06, Len Ovens <[email protected]> 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 > accountants. > > 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: > 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. > > 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 > www.ovenwerks.net > > _______________________________________________ > Linux-audio-dev mailing list > [email protected] > http://lists.linuxaudio.org/listinfo/linux-audio-dev > >
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
