[linux-audio-dev] OSC, mDNS and LASH: a good combo?
S.W.Harris at ecs.soton.ac.uk
Mon Feb 28 21:35:34 UTC 2005
On Mon, Feb 28, 2005 at 09:09:49 +0000, Martin Habets wrote:
> My impression is that more and more applications are moving to
> OSC for inter-process communication.
> Question 1: Are most audio/midi applications converging on OSC?
> Are there any moving away from it? Or are there other strong
> contenters in this area?
> AFAIK all linux audio/midi applications use an arbitrary UDP port
> number, and rely on manual configuration of this for the server and
> all clients.
> With OSC popularity increasing this will pose a growing problem
> for end users who have to configure the ports, and for developers
> of client programs that want to interact with multiple servers.
> The answer to this issue is service discovery, which was recently
> discussed on the OSC_dev list . That thread leads to a product
> called howl , 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.
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.
> 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.
> 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.
I did consider this solution when I started implementing liblo, but
rejected it as too OSC specific.
Dave Robillard (sp?) has an another OSC-based idea that covers some of hte
same ground, but I'l leave him to describe it.
More information about the Linux-audio-dev