Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Thu May 03 2001 - 15:36:42 EEST
On Thu, 3 May 2001, Jim Peters wrote:
> I'm wondering if now is the moment to take a step back and figure out
> where we've got to with this and where we're heading. I've just been
I think we're rapidly approaching the "show us the code" phase. ;) I
actually have already writing some draft code. I think it's probably best
to first write a _very_ bare bones implmentation to test the ideas. If it
turns out good, then it's time to finalize to public APIs. As for
schedule, this month is quite busy for me (ecasound's 2.0.0 release, etc),
but afterwards I probably can spend some time with this.
> - Plugin interface, how they are called, how they are setup,
[...]
> - Server interface, how external processes can request that a plugin
Here's a draft of the callbacks. I've tried to stay close to Paul's AES
interfaces.
--cut--
typedef struct _laaga_server_callbacks {
void (*prepare)(void);
void (*start)(void);
void (*stop)(void);
int (*request_channel)(int direction);
void (*release_channel)(int direction, int channel);
void (*write_to_channel)(int channel, void* buffer, long int count);
void (*read_from_channel)(int channel, void* buffer, long int count);
} laaga_server_callbacks_t;
typedef struct _laaga_client_callbacks {
void (*init)(const laaga_server_callbacks_t* s_callbacks);
void (*cleanup)(void);
void (*prepare)(void);
void (*start)(void);
void (*stop)(void);
void (*process)(void);
} laaga_client_callbacks_t;
--cut--
Few points:
- common transport functionality (prepare,start,top) which can
be triggered by any of the clients, or the server
- integer indices for channels (assigned by the server)
- distinction between input and output channels
- clients can request/release channels (either input or output)
from the server
- for processing, server issues client->process(), and client can
then use the read_from_channel() and write_to_channel() funcs
provided by the server (-> allows server to perform basic ops
like mixing, gain, panning, etc directly when writing to,
or reading from the bus)
- additional threads/processes can be launched from client's
init() functions
- no dynamic allocation; plugins are instantiated from the
server
1. server is loaded
2. user selects which plugins she wants
3. server loads the plugins and issues init()
4. plugins start their own processes/threads and then request
channels for all their input and output ports
5. someone issues start() and we're rolling
But that's about it. There are quite a few technical details (handles for
passing plugin private data, what to do when exiting server/clients, etc).
> - Crash and restart-handling. This server (even once stable in
> itself) is likely to crash a *lot* whilst new plugins are being
> developed and debugged, and it would be good to bear this in mind
> whilst designing the interfaces to external processes. Restarts
> would be required if the sample rate was changed.
The sampling rate issue is always a bit tricky. Hmm, maybe we should just
pass the engine sampling rate in the client->init() call and plugins would
be required to use that.
> - Security. Given that we're presumably loading plugins for any
> external app that asks us to, we need to have fairly low privileges.
> How does this mesh with some of the high privileges we'll probably
> need ? Do we need to somehow vet the external apps that are making
> the requests ?
This is an important thing to keep in mind, but at the moment I'd like to
concentrate on the basic functionality, without worrying about security.
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Thu May 03 2001 - 15:40:46 EEST