[linux-audio-dev] OSC, mDNS and LASH: a good combo?

Martin Habets errandir_news at mph.eclipse.co.uk
Tue Mar 1 14:58:08 UTC 2005

On Tue, Mar 01, 2005 at 01:27:38PM -0500, Dave Robillard wrote:
> So basically my goals are to make OSC using liblo as nice as audio using
> jack, as far as "ports" and "connections" (in jack-ese) go, with as
> little burden on clients as possible, and allowing user patching, etc.

It seems our goals are the same, although user patching should not be
needed IMO.

> > The answer to this issue is service discovery, which was recently
> > discussed on the OSC_dev list [1]. That thread leads to a product
> > called howl [2], which is an open implementation of mDNS/redezvous/
> > zeroconf (take your pick). It provides 3 daemons (of which 2 should
> > be run) and some libraries.
> > Using this implementation all applications would (ideally) register
> > or discover services using the howl libraries. Apart from this, the
> > programs would communicate via OSC.
> > 
> > To me this seems like a lot of overhead for a relatively small gain.
> > OTOH it seems like a very flexible and future-proof solution.
> It is overhead at connection establishment time - irrelevant to actual
> performance.  Rendezvous is the way to do these things, no question.  It
> will only get even more popular over time.

Yes, rendezvous is the general purpose answer to the problem. It will get
more used over time, and it is exactly that which may pose a problem.
But what happens when someone turns on the rendezvous-enabled washing
machine during your recording session? Or consider the M$ Windows machine
that publishes, retracts and queries like crazy. You'd have to create
a subnet for your audio studio to artificially limit the scope of

At the moment rendezvous is a very open/liberal system. I'm all for that
off course, but with growing popularity I think it will gain some security
features. That could be bad news for folks who just want to get together
and jam.

> > An alternate way I've been considering is an OSC-based service
> > discovery daemon. It would accept OSC messages to register and discover
> > services. The advantage of this is that it only uses 1 small daemon,
> > but more importantly that applications do not need to use any additional
> > libraries besides the OSC one (<insert liblo plug here> :). So far I
> > can see 6 input messages for such a daemon, with 4 response messages.
> > The disadvantage is that the daemon would still need an arbitrary port
> > number, and all applications would need to know it (at least for a while).
> > For intra-host discover the daemon could still interact with howl or
> > something like it if that is needed. But if this approach is successfull
> > we could request one dedicated port from IANA.
> > 
> > Question 2: Are there other better alternatives?
> > Question 3: Which alternative is better or do you prefer? (mDNS/OSC-daemon)
> Actually, the solution myself and Steve Harris came to (on #lad) is a
> combination of both.  In order to accomplish user "patching" and relieve
> the burden on clients, an OSC daemon will be required to maintain
> information about what is patched to where, etc.  However, rendezvous is
> needed so things can discover each other (ie clients can discover the
> patching daemon, and vice versa).

I was thinking along the same lines here. But the point is that if you
use rendezvous only for daemon discovery, then the overhead costs more than
the benefit you gain (remember every application would need it).

> The "patching server" (called that from hereon for lack of a better
> name) has simple commands like /set_destination
> <url>, /remove_destination <url>, etc.  You can imagine a GUI
> jack-patch-bay like client for it.

I don't like the idea of yet-another-patch-bay for this. It just pushes
the problem out to the end users, most of which do not know (or want to)
what to connect where. Besides, the application developers know much better
which services their application want.

For example, the sooperlooper GUI is only wants to find sooperlooper
engines. It is not interested in whatever jack.osc offers.

Note I don't object to having a patch-bay for this, but I think it should
not be the main way to make connections. Rather just for viewing and maybe
adjusting later.

> >From the client side, this will all be abstracted in liblo behind a
> simple jack-like API (where the client code doesn't know or care where
> it's messages go).  I think this is best, and in fitting with liblo's
> general philosophy.
> Implementation wise, the scheme goes something like this:
> - client broadcasts it's existance via rendezvous
> - patching server replies to client, so now both are aware of each
> other's existance
> - (any) client can now set destinations for client.  in other words,
> osc-patch-bay functionality now works

I see the usage scenario as follows:
- client does a broadcasts to the oscsd port of a "/ping" message.
- oscsd acknowledges it.
- client request a service using a "/request service_name" message.
- oscsd responds with either the URL of the server, or responds with
  a negative acknowledge if the service has not registered.

For servers (i.e applications providing services) the first 2 steps
are the same. After that is publishes it's services using
/register service_name service_URL

An application can provide multiple services, and register to multiple
services as well. It can use one port or multiple, use one OSC address
or many.

> When a destination is added/removed, the patching server will notify the
> client (via OSC), and the client will update it's list of destinations
> appropriately (this will all be abstracted by liblo's API though).
> And that's it.  No more manual port specifying nonsense, and clients
> connection code has been reduced to probably a single liblo function
> call (and a special lo_address token that means "send to all my patch
> bay destinations")
> The nice thing about this system (thanks largely to Steve) is that it
> will also work with non-liblo clients, and so could become an OSC
> 'standard' if it catches on.  At the very least it will promote OSC to
> the same level of modularity that MIDI and Jack have, as far as linux
> audio systems are concerned.  Plus, since everything is network
> transparent, programs run on other machines on the network will
> automatically register their (er) "ports", so could magically appear in
> other machine's patch bays - very cool.

Yep, same here.

> I'm planning on writing this thing really soon, unless anyone has a
> better idea.  The actual server will be almost trivial, just the service
> discovery and liblo abstraction will be slightly more annoying to
> implement.

I'd recommend writing down the full spec first, and send that out for
review. That's what I'll be doing :)


More information about the Linux-audio-dev mailing list