Subject: Re: [linux-audio-dev] a port/buffer proposal
From: Vincent Touquet (vincent_AT_ulyssis.org)
Date: Tue May 22 2001 - 07:44:18 EEST
Paul Davis wrote:
> * how about the connection between i/o ports inside a Plugin?
> -------------------------------------------------------------
>
> thats handled differently. this is always a 1:1 connection, and can
^^^^^^
No comments up till now, but here I find myself genuinely lost...
Surely, how the plugin gets from his M input ports to its N output ports, can be left
to the imagination of the plugin.
Why do we need a 1:1 in/out mapping of the ports ?
Looking at your proposal, this restriction is not needed ?
> [more cutting happened here]
> * when does all this stuff happen?
> ----------------------------------
> in a naive model, it happens on every engine cycle.
>
> in a more sophisticated model, the memory buffers are requested
> whenever the signal graph is modified. the rest of the stuff happens
> on every engine cycle.
>
Great, so in this sophisticated model, we could do very good buffer reuse.
As you stated further in the proposal, when every connection is 1:1, only
one buffer would be needed.
Now define a 'stage' as all the connections that are at a given distance L from a
given source (in the simplest case one source).
Then the connections at distance L+1 could reuse some of the buffers of the
connections at distance L, depending on the typpe of the connections at the latter
level of course. It definitely leaves room for optimisation. Great.
The only problem I would see in buffer reuse would be with feedback, (well not exactly
a huge problem).
A buffer which is involved in a feedback loop can never be reused at any point in the
cycle.
> * what does it really look like?
> --------------------------------
> This is a mixture of pseudocode and real code for the naive model.
>
> struct Connection {
> Connection *next;
> Port *input;
> Port *output;
> gain_t gain;
> };
>
Now I see here a possibility for confusion.
At least i was confused when I read your code.
It has to do with what you consider the input or output of a connection.
I think it would be easier to understand, if you would call the input of the
connection, that port that is the output of the plugin connected to the connection
and the other way around: the output of the connection is the input port this
connection is connected to.
This leads to more natural behaviour, where within a connection, the data flows from
the connection's input, to the connection's output... This makes sense to me, but it
might not to you ? It could make the code easier to understand ...
Anyone also agreeing on this, please speak up, else lets move on.
> [cut]
> /* input port */
>
> if (port->connection_cnt == 1) {
>
> /* One-to-One or One-to-Many */
>
> Connection *connection = port_get_nth_connection (port, 0);
>
> if (connection->gain == 1.0) {
>
> /* use zero-copy data transfer */
>
> port->buffer = connection->output->buffer;
>
port->buffer = connection->input->buffer; (pleasee ? ;-)
> [cut]
> * your turn
> -----------
> --p
Well, I have looked over it several times, and I like it basicly.
As said before, we could also allow MxN connection with some gain 'k', if we would
split it in N Mx1 connections with gain 'k'. Changing this gain k, would then have to
change these M gains 'k'. This would require some managing from the part of the
engine.
Now, you won't be seeing me till in a month or so and I already fear the amount of
catching up I'll have to do :-)
Exams :(
Kind Regards
Vincent
This archive was generated by hypermail 2b28 : Mon May 21 2001 - 23:12:36 EEST