Re: [LAD] OPEN CONTROL ARCHITECTURE

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" <len@email-addr-hidden> wrote:

> On Fri, 27 Feb 2015, Frederick Gleason wrote:
>
> On Feb 27, 2015, at 18:04 06, Len Ovens <len@email-addr-hidden> 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
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Feb 28 08:15:01 2015