Len Ovens len at ovenwerks.net
Fri Feb 27 23:04:06 UTC 2015

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:
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

More information about the Linux-audio-dev mailing list