Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Jim Peters (jim_AT_uazu.net)
Date: Mon May 14 2001 - 10:48:21 EEST
Jim Peters wrote:
> add_port(handle, &floatpvar, 1, "1"); # Create output port "1"
> connect_port("AAA-1", "BUS-23");
I've been thinking some more on this since my posting last night. It
seems to me that in Paul's model, the plugin itself has to do the job
of the mixer - i.e. the plugin must supply one or several feeds,
ideally all at independent gain-levels, to one or more busses. It's
like the plugin is taking the place of not only the device generating
the sound, but also the whole mixer strip that that device is plugged
into (on a mixing desk).
I guess this is a choice, a design decision. I personally don't think
that's the job of a plugin. However, to get my proposal to do the
same, I need to add a gain-level to every connection, like so:
int okay= connect_port(char *src, char *dst, double gain);
This means that the plugin writes its output into the buffer provided
by the server, and then the server will relay that to one or more
destinations (which may be busses, or may be other plugin inputs),
possibly adjusting the level in the process (if gain != 1.0). If
there is only one connection of gain==1.0, the server can skip the
relaying and give the plugin the destination buffer directly,
optimising out the intermediate copies.
In the non-optimised case, we're back to what happens in AES - writing
a buffer, then relaying on to several other buffers with gain
adjustments. The difference here is that the server is in charge of
the relaying, not the plugin, and other plugins can adjust the
connections without requiring any cooperation from the source plugin.
How does this look ? I'm definitely looking for feedback here.
...
I've also realised that the `handle' argument to add_port and del_port
isn't doing anything useful, so these need to be:
add_port(float **floatp_varp, int direction, char *name);
del_port(float **floatp_varp);
The server would have to pick up which plugin this applies to from the
context, and if it can't do that, we'd have to add some other
handle-type argument back in.
The details of these function calls I'm proposing are all quite rough
right now - the names, the arguments, and their order. This all needs
cleaning up probably.
I hope this is good enough as a basis for discussion, though.
Jim
--
Jim Peters (_)/=\~/_(_) Uazú
(_) /=\ ~/_ (_)
jim@ (_) /=\ ~/_ (_) www.
uazu.net (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
This archive was generated by hypermail 2b28 : Mon May 14 2001 - 11:07:24 EEST