28 Feb
2015
28 Feb
'15
12:05 a.m.
Has anyone looked at OCA as a method of service discovery/remote control
for Linux audio? This is supposed to end up as another aes* "real soon
now" but the current spec is available at:
http://ocaalliance.com/technology/specifications/
For the downloading and there are some products out there that use it now.
(well at least one anyway)
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. (Some other
AoIP things might be better)
So along the way I stumbled on OCA. This is not another OSC, though it
could do that job too.
I will put this in terms of Linux/ALSA/Jack because that is what I know.
As an example assume two linux boxes, one with an Audio IF and another
with audio SW, A and B. Box A is headless, boots up with jack running. Box
B has no Audio IF because it is new and only has PCIe sockets, other than
that has everything a normal Desktop would have as a DAW.
The way OSC works would be for the user on Box B to open a window
something like the "Connections" window on qjackctl. It would show all
local connections the same as Qjackctl does now... System on both sides
that can be expanded, it would also show "Box A"... but when clicked to
expand, a box would pop up showing what lines are local there on Box A's
Jack. There would be a dropdown/whatever that allowed the user to set the
number of lines to set up between the boxes in which direction. SO the
user does that. Now the user can connect whatever Box A internals to these
I/O lines and the BOX A on the local window will now expand to show those
lines which will be labeled the same as on BOX A. All of this in one app.
But there would be more. Next we want to set the actual ALSA device
levels, so we open an ALSA mixer, one of the devices will be Box A's ALSA
card and the levels can be set.
Now because Box A really isn't doing too much, we want to run a soft synth
on there as well, So long as the OCA server already understands tha SW, it
would already show as a capablility of that box. The I/Os would show up as
if they were already available on the jack graph, but the app would not
yet be running (because there may be a number of different ones available)
but as soon as one of those connects was connected, the OCA server would
start that synth and make the connections when it was started (MIDI and
audio). Clicking on any of that synths i/o's would give the user a control
interface with that synth.
This to me is the way remote discovery/control should work. Does that make
sense? Does this look like I have read the OCA spec right? Does this sound
worth while?
I have only scratched the surface to give some idea what we are talking
about. OCA would not replace MIDI or OSC, but it could find them and
connect them from one box to another. Some of the kinds of controls OCA
has might be better for remote control of mixer kinds of things like
faders, sends, eq and such because these things are defined already and
where not, any other controls are discoverable/query-able and could be set
up on the fly in SW (not so much for HW). This is the same thing that
already happens with ALSA controls and ALSA mixer.
Anyway, I am going to try making a server and client based on this spec.
--
Len Ovens
www.ovenwerks.net
28 Feb
28 Feb
1:11 a.m.
On Feb 27, 2015, at 18:04 06, Len Ovens <len(a)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. 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.
(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.
Just my $0.02 US.
Cheers!
|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|----------------------------------------------------------------------|
| There are two ways of constructing a software design. One is to |
| make it so simple that there are obviously no deficiencies; the |
| other is to make it so complicated that there are no obvious |
| deficiencies. The first method is far more difficult. |
| --C.A.R Hoare |
|----------------------------------------------------------------------|
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. 
6:07 a.m.
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(a)ovenwerks.net> wrote:
On Fri, 27 Feb 2015, Frederick Gleason wrote:
On Feb 27, 2015, at 18:04 06, Len Ovens <len(a)ovenwerks.net> wrote:
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
That too is possible. Even 800 pound gorillas like candy.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Some background: I have been looking at AoIP and reading what I could.
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
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.
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)
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.
7:49 a.m.
On Fri, 27 Feb 2015, Jesse Cobra wrote:
Is 1722.1 of any use for this?
http://standards.ieee.org/findstds/standard/1722.1-2013.html
Hard to tell. What I can find out about it seems to indicate that it is
closely tied to AVB. It may be possible to just use the parts that make
sense outside of AVB, but I think it would no longer meet the standard
which then asks why use it. The entry costs on all things AVB are higher
than I can afford.
--
Len Ovens
www.ovenwerks.net
2:51 p.m.
On Feb 28, 2015, at 00:00 29, Len Ovens <len(a)ovenwerks.net> wrote:
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.
Or in traditional Un*x terms: the mechanism has been specified, but not the policy.
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.
Compatibility is strictly at the RTP level. The control systems (not to mention little
details like GPIO transport) inhabit completely different planets. I don’t see that
changing anytime soon.
Cheers!
|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|----------------------------------------------------------------------|
| There is only one thing worse than having your competitors trying |
| to inter-operate with your systems - and that is to have your |
| competitors *not* trying to inter-operate with your systems. |
| --Alan(UK), GrokLaw.net |
|----------------------------------------------------------------------|
8:39 p.m.
Late to this discussion but why not a combination go zeroconf and osc for
all this discovery and control?
I have always been surprised someone has not already written an OSC to alsa
mixer controller...
On Sat, Feb 28, 2015 at 5:51 AM, Frederick Gleason <fredg(a)paravelsystems.com
wrote:
> On Feb 28, 2015, at 00:00 29, Len Ovens <len(a)ovenwerks.net wrote:
>
> > 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.
>
> Or in traditional Un*x terms: the mechanism has been specified, but not
> the policy.
>
>
> > 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.
>
> Compatibility is strictly at the RTP level. The control systems (not to
> mention little details like GPIO transport) inhabit completely different
> planets. I don’t see that changing anytime soon.
>
> Cheers!
>
>
> |----------------------------------------------------------------------|
> | Frederick F. Gleason, Jr. | Chief Developer |
> | | Paravel Systems |
> |----------------------------------------------------------------------|
> | There is only one thing worse than having your competitors trying |
> | to inter-operate with your systems - and that is to have your |
> | competitors *not* trying to inter-operate with your systems. |
> | --Alan(UK), GrokLaw.net |
> |----------------------------------------------------------------------|
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
10:31 p.m.
On Sat, 28 Feb 2015, Jesse Cobra wrote:
Late to this discussion but why not a combination go
zeroconf and osc for all
this discovery and control?
I have always been surprised someone has not already written an OSC to alsa mixer
controller...
OSC is good because it is wide open... and bad because it is wide open. No
two applications seem to use OSC commands that are the same as another.
OSA starts with a framework that is the same from one device/application
to the next. OSC is not dead, but it is not able to do auto setup. Having
used zeroconf to find an OSC server, there is no way to discover what is
there to control. The user has to know that already and prepare the
controller to talk to the device/application. OSC does have a query setup
in development, but it has been that way for a number of years now. It
seems funding for the main contributions has gone away. (this is as far as
I can see http://opensoundcontrol.org/spec-1_1 ).
in OCA:
zeroconf is used to find the device, the controller/application connects,
it gets a list of objects, what is controlable and the signal path through
those objects. It is now possible for SW to create a GUI with controls
that make sense and have labels on them. The controller can find out the
value of any control's parameter that it can control. (provided the writer
of the OCA server does their job) Take a look at OSC for Ardour, it is
quite good, but a controller does not know how many routes there are
unless the user tells the controller. Sending fader changes to route 32
out of 24 does not crash Ardour, but it gives no feedback either. This is
not Ardour's fault so much as a hole in OSC. (or maybe an elevated
expectation of OSC :)
So think about the OSC to ALSA mixer server and client. The server can use
the standard ALSA tools to find out what all the controls are and create
OSC paths for them. Cool. The client connects... it has to have a template
for all the same cards alsa knows about and the client user has to tell
the client which one to use. In other words the client/controller is a
deddicated unit just for alsa mixing, it can do nothing else or at least
needs a prewritten profile for anything it does.
--
Len Ovens
www.ovenwerks.net
11:57 p.m.
On Feb 28, 2015, at 16:29 22, Len Ovens <len(a)ovenwerks.net> wrote:
OSC is good because it is wide open... and bad because
it is wide open. No two applications seem to use OSC commands that are the same as
another.
Right. It’s the ‘mechanism, but no policy’ conundrum all over again.
I have no particular beef against OSC or OCA. However, there is already a small multitude
of AoIP control protocols out there (Dante, JetNet, LiveWire, Q-Lan, WheatNet, …). I
don’t think that adding Yet Another Incompatible Protocol is fundamentally going to
improve this situation. What would be far more helpful would be a decent FOSS library for
supporting one of the quasi-dominant AoIP systems; something that could help push that
system over the top to make it the defacto industry standard. Today, in the pro
audio/broadcasting space, there are really only two realistic contenders for this role:
LiveWire or Ravenna. Pick one.
Cheers!
|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|----------------------------------------------------------------------|
| It is computed that eleven thousand persons have at several times |
| suffered death, rather than submit to break their eggs at the |
| smaller end. |
| -- Jonathan Swift |
| "Gulliver's Travels" |
|----------------------------------------------------------------------|
1 Mar
1 Mar
2:58 a.m.
https://github.com/audioscience/avdecc-lib
With AVB endpoints down to a few hundred bucks it seems the cost of entry
is becoming acceptable...
On Feb 28, 2015 2:57 PM, "Frederick Gleason" <fredg(a)paravelsystems.com>
wrote:
On Feb 28, 2015, at 16:29 22, Len Ovens
<len(a)ovenwerks.net> wrote:
OSC is good because it is wide open... and bad
because it is wide open.
No two applications seem to use OSC commands that are the
same as another.
Right. It’s the ‘mechanism, but no policy’ conundrum all over again.
I have no particular beef against OSC or OCA. However, there is already a
small multitude of AoIP control protocols out there (Dante, JetNet,
LiveWire, Q-Lan, WheatNet, …). I don’t think that adding Yet Another
Incompatible Protocol is fundamentally going to improve this situation.
What would be far more helpful would be a decent FOSS library for
supporting one of the quasi-dominant AoIP systems; something that could
help push that system over the top to make it the defacto industry
standard. Today, in the pro audio/broadcasting space, there are really
only two realistic contenders for this role: LiveWire or Ravenna. Pick one.
Cheers!
|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|----------------------------------------------------------------------|
| It is computed that eleven thousand persons have at several times |
| suffered death, rather than submit to break their eggs at the |
| smaller end. |
| -- Jonathan Swift |
| "Gulliver's Travels" |
|----------------------------------------------------------------------|
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
3 Mar
3 Mar
12:25 a.m.
On Sat, 28 Feb 2015, Frederick Gleason wrote:
Right. It’s the ‘mechanism, but no policy’ conundrum
all over again.
This is a big one all right.
I have no particular beef against OSC or OCA.
However, there is already
a small multitude of AoIP control protocols out there (Dante, JetNet,
LiveWire, Q-Lan, WheatNet, …). I don’t think that adding Yet Another
Incompatible Protocol is fundamentally going to improve this situation.
What would be far more helpful would be a decent FOSS library for
supporting one of the quasi-dominant AoIP systems; something that could
help push that system over the top to make it the defacto industry
standard.
I completely agree.... except, they don't seem very open. A lot of them
are not very good either. There seems to be an inverse trend of openness
to goodness. The more open things are the worse they are too.
Today, in the pro audio/broadcasting space, there are
really
only two realistic contenders for this role: LiveWire or Ravenna. Pick
one.
These two are basically no standard. Zeroconf for discovery and then web
browser for everything else. This is ok for something that will be set up
once during install and then will be used with that one set up there
after. (I have been reading device manuals) For a lot of Broadcasting set
ups this is probably fine. For live sound it is not... probably Dante is
bigger there though, but completely closed as it is the only thing that
feeds money to Audinate (who are now a partner with OCA BTW). Every audio
console maker that has split controler/mixer or digital snake seems to
have their own control system as well, mostly based on MIDI as far as I
can tell (they don't tell, just let some things slip :)
For the uses I see in Linux, the browser approach is always available, it
is the device setup standard pretty much across everything. Every embedded
OS supports some sort of web server. But this stuff is slow for live
control. MIDI is the thing people use right now for RT control, but it is
not at all standard or discoverable.
I see your point about defacto standard. The MCP is a good example, not
the best protocol, quite limited with only 16 faders. The Yamaha MIDI
mixer control is much better (Allen & Heath allows more controls but at
lower rez too and I am sure there are others).
If I make some OCA kinds of things, it will be because I see a use for it.
It will help me in my setup or others with a similar small setup. It has
been a long time since I was in the broadcast world and if I get back in
it will be in a small setup as I am not willing to move back to "the big
city". In that case I will be working with whatever they have anyway.
A quick note on Audinate. They are a partner with OCA as they were one of
the players in AES67. They are the only player from AES67 (that I can see)
that have not yet released anything that allows Dante devices/sw to work
with AES67 which they promised for the end of 2014 (the promises are still
on the website :) Their involvement in OCA does not in my mind mean they
will support OCA in any way and may be only making sure none of their
patents are disturbed. Audinate has the most to loose with any new
standard as their business is their protocol. Other network standards seem
to be linked with hardware. So the company has less to loose by supporting
another protocol so long as they include it with their hardware. It may in
fact allow them to streamline their product line by dropping some bits and
concentrate on the most profitable bits. If OCA is released in the next
few months as a standard (as it is supposed to be), another year will tell
if it is going to be used. Ravenna and Livewire (not to be confused with
LiveWire(tm) which is a motorcycle, or Livewire
http://static.comicvine.com/uploads/original/1/19859/846008-livewire__anima…
) both could bennefit from OCA as far as I can see though as you say they
may not feel the need to.
--
Len Ovens
www.ovenwerks.net
3352
days inactive
3355
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
3 participants
participants (3)
-
Frederick Gleason -
Jesse Cobra -
Len Ovens