Re: [Linuxsampler-devel] LinuxSampler API

[David O. <da...@ol...>]

On Saturday 27 December 2003 03.05, Christian Schoenebeck wrote:
> Hi!
>
> It's time to design an API for LinuxSampler to allow communication
> between GUI frontends and sampler engine. I would like to hear your
> opinions about that.
>
> I think the API should be plain C (anybody against that?).

C sounds like a good idea to me, with portability and compiler=20
compatibility in mind. It's also pretty much the lowest common=20
denominator when it comes to binding with other languages, including=20
scripting languages.


> The
> question is using only POSIX functions for the communication
> internally or using more sophisticated libraries for that. Marek
> suggested D-BUS for example:
>
> =09 http://www.freedesktop.org/Software/dbus

Well, I haven't used D-BUS, but it seems to me that for one library to=20
talk to one daemon/engine, it's almost overkill to use even the POSIX=20
IPC stuff. All we need is a simple binary or ASCII protocol that can=20
be piped through pipes, TCP/IP, UDP (needs an extra protocol layer),=20
shared memory, lock-free FIFOs or whatever. (Check out FluidSynth to=20
get an idea of what I have in mind.)

When that's in place, all that remains to implement, apart from the=20
package sending and receiving, is making the connection. Most=20
importantly, we have to figure out how to connect the right client to=20
the right engine, which may not be totally obvious if there can be=20
many of each within the "address space" of the transport layer in=20
use.


> Sending a command from the frontend to the engine would be a simple
> function call for the frontend application, e.g.
>
> =09hEngine =3D connect_to_engine(ip_address, port);
> =09...
> =09int res =3D load_instrument(hEngine, instrument_file, channel);

Or, if an ASCII protocol is used, and it's simple enough, you could=20
just expose that. Makes for a very simple API, in terms of function=20
calls, but of course, then the protocol becomes part of the API.=20
(Means we can't easilly switch to a streamlined binary protocol later=20
on, for example.)

Anyway, I don't quite like the return value part. A communication API=20
with roundtrip returns pretty much implies an RPC style protocol,=20
which means that every call requires a "hardsync'ed" roundtrip. Doing=20
it asynchronously requires a slightly different client application=20
design (although an application *could* implement a synchronous=20
layer, of course), but it's a lot more efficient, especially when=20
dealing with ethernet and the like.

Note that asynchronous communication mixes pretty well with the event=20
based design of most GUI applications.


> Whatabout the reversal, e.g when the engine wants to inform the
> frontend, that the voice or disk stream count has changed? Should
> we simply use normal C callback functions?

Callback functions imply that the client lib can somehow get the CPU=20
when it needs to make a callback. This makes it unclear exactly when=20
a callback function can be called, and it can get real hairy in=20
multithreaded applications.

Anyway, one solution is to have an extra thread that handles data from=20
the engine, and communicates with the client through callbacks. This=20
introduces tons of sync issues in the client code, so it's pretty=20
much a last resort solution, and I'd only recommend it for real time=20
applications, and applications that are somehow heavily multithreaded=20
by design anyway. (Ie the sync constructs are in place anyway, so you=20
might as well use them. I would not design an application like this,=20
unless I really have to, to support SMP or something.)

Another solution is to make the API event based, similar to SDL and=20
most GUI toolkits. I would strongly recommend against the usual "take=20
over the main loop" approach that most GUI toolkits take, though. An=20
API with calls that allow polling and blocking waits on events blends=20
much better with any type of client code. It's easy enough to add an=20
event handling thread on top of this, if you actually have a design=20
where that is more appropriate.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---