[linux-audio-dev] OSC, mDNS and LASH: a good combo?
errandir_news at mph.eclipse.co.uk
Tue Mar 1 09:15:46 EST 2005
On Mon, Feb 28, 2005 at 09:35:34PM +0000, Steve Harris wrote:
> There is a proposed specification for discovery of OSC services that was
> presented at hte OSC conference, I intend to support it in liblo at some
> point in the future.
Do you have a link to this spec? Was it the one based on zeroconf?
> > 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.
> IIUC Gnome allready requires libhowl and mDNSResponder, so its not as
> burdonsome as it could be.
Not sure what you mean by the gnome connection. I would recommend against
running gnome (or KDE) when doing audio work, but that's just my angle on
> > 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.
> That is not as appealing to me, as the service will only be discoverable
> on the local machine, whereas MDNS works on local networks.
That's just a matter of broadcasting. If the daemon listens on port 1234
it will respond to any client to that broadcasts to that port.
> I did consider this solution when I started implementing liblo, but
> rejected it as too OSC specific.
I agree it is OSC specific, but in my opinion that is big adavantage ad no
other protocols/daemons/libraries are needed.
More information about the linux-audio-dev