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

Steve Harris S.W.Harris at ecs.soton.ac.uk
Tue Mar 1 20:32:48 UTC 2005


On Tue, Mar 01, 2005 at 02:58:08 +0000, Martin Habets wrote:
> 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.

I dont think thier actually the same, they just overlap to some extent.
Both of these things are needed, but one is allready defined (zeroconf+the
OSC specific stuff), and one needs some thinking.

Dave is trying to solve exactly the case where you *do* want to manually
connect applications. He has examples.

> > > 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
> rendezvous.

Not at all, theres a protocol prefix for OSC, which washing machines are
unlikly to speak :) so washing machines will be ignored by OSC things.
Also, there is a field that you can use to descriminate between OSC
services that use particular schema.
 
> 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.

I really dont think so. It doesnt make sense to add seurity to redevous
itsself, if you want secure, discoverable services then use IPSec. Its a
different layer.
 
> > > 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).

No, the benefit is that the application can send to one or more
destinations without the author explicitly coding some discovery stuff,
and be changable dynamically. Thats not possible without

1) some discovery
2) a service (in the looses sense) that tells you where to send things
 
> > 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.

I thought so to, but Dave has some counter examples.
 
> For example, the sooperlooper GUI is only wants to find sooperlooper
> engines. It is not interested in whatever jack.osc offers.

Right, but thats not true in all cases.

For the record I will not add support (or accept patches) to liblo for any
discovery mechanism that does not use an existing standard. I know just
enough about the area to know that there are subleties of the problem that
I dont get, and there are plenty of known-good standards in this area, of
which redevouz/zeroconf is probably the most appropriate.

- Steve



More information about the Linux-audio-dev mailing list