|
From: David O. <da...@ol...> - 2003-12-28 13:16:41
|
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 --- |