Subject: Re: [linux-audio-dev] laaga implementation news bite
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Jun 11 2001 - 14:39:25 EEST
>Note that here you doubled the cost compared to a pull model (you would
i don't understand. how has this doubled the cost? i know there
is extra cost from supporting multiple processes, but i don't
see an algorithmic doubling in the model. can you explain?
>call it that way? I.e. I'm speaking of a model like GLAME does with
>threads) - and I dont think you need an "engine" at all if
>you are asynchronous anyway (at least you shouldnt depend on one).
if you read Kai's LAAGA "papers", you'll see that LAAGA must be
designed around synchronous operation driven by the audio
interface. async operation is not an option unless there is
a big fat buffer (read: "latency") between the async client/plugin
and the actual engine.
>is, I dont like the callback at all as it is not flexible at all. You
>can wrap a callback model around any other model in a small lib, but
>you can't do otherwise.
1) more or less every other player in the audio market *does* like
the callback model.
2) you can wrap a callback model, but you add latency doing so.
>Note that you'll get bite by using kill here - you'll need to lock
>against concurrent signals during malloc() (If you ever allow malloc
>from the signal handler).
1) there are no signal handlers, we use sigwait(3)
2) we never use malloc or new in the audio thread
3) signals are not received asynchronously anyway. they are
driven entirely by the audio interface, and the sequential
synchronous interaction of the engine with each client.
>Note that I have done shared memory management code for multiple
>processes before (I have even an implementation ready - search for
>datamanager in freshmeat or go to
>http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/DataManager/datamanager.
>html
>you'll find the interesting part in the buffer.[ch] files.
thanks. i'll check this out. it may not be quite right for
the purpose, since the objects are all a fixed size, and so
i really need a "pool"-like approach (with only very occasional
calls to actually get more memory). but this will be helpful.
>I'd like to see how you are using kill (i.e. how do you do callback
>operation between a manager and a process at all!??).
client (within a library call):
sigwait (&signals, &sig);
switch (shm_control_block->event) {
case ProcessEvent:
shm_control_block->process (shm_control_block->nframes);
break;
...
}
kill (shm_control_block->next_pid, sig);
engine:
kill (client->pid, relevant_signal);
>Richard, who still thinks your approach is flawed.
do you have an alternative? if you drive multiprocess clients
with pipes, then reconfiguring the graph is a lot of work since
you have to alter every client's idea of what the "next" client
to execute is. that's my reason for using kill(2).
but its also not particularly relevant to LAAGA itself, since its
just an implementation detail. if its the wrong approach, i'd
welcome a better method.
--p
This archive was generated by hypermail 2b28 : Mon Jun 11 2001 - 16:09:20 EEST