On Mon, 2005-28-02 at 21:09 +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.
This is definitely a huge problem. I'm working on numerous OSC
projects, and the connection establishing code is by far the most
annoying thing to do. I eventually came to the conclusion that clients
shouldn't have to deal with all that nuisance.
We have these nice patch-bay-like systems with Jack and Alsa that are
touted as the best thing since sliced break around here, but nothing
similar for OSC. The benefits are the same, except the downsides
of /not/ having such a system are worse (ie it's much more a PITA for
developers to figure out their OSC connections than just send along some
MIDI channel number or device file).
Consider a simple OSC sequencer that just records it's input and then
sends it out later - where does this input come from? It has no idea.
Where does it go? Who knows. Must every little app have hundreds of
lines of service discovery just to integrate with the system? Whether
this is needed or not isn't up for debate, just how to accomplish it
is. :)
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.
> 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.
> 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).
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.
>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
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.
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.
Cheers,
-DR-
Received on Tue Mar 1 08:15:04 2005
This archive was generated by hypermail 2.1.8 : Tue Mar 01 2005 - 08:15:05 EET