[LAD] OPEN CONTROL ARCHITECTURE

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev