Re: [linux-audio-dev] a port/buffer proposal

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] a port/buffer proposal
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 22 2001 - 23:00:00 EEST


>> void
>> port_tie (Port *dst, Port *src)
>> {
>> dst->buffer = src->buffer;
>> }
>>
>> will work for Plugin's that want their outputs wired directly to their
>> inputs.
>
>Slight confusion here. Is this something that a plugin must call
>every process() call, or is this something that the plugin sets up
>once only ?

Once only. Sorry for the confusion.

>> struct Connection {
>> Connection *next;
>> Port *input;
>> Port *output;
>> gain_t gain;
>> };
>
>On the question of NxM matrices and so on (commented on in discussions
>over the last few days), my take on this is that this model is a way
>of understanding it, but not the way it is actually implemented.
>There is no point in creating hundreds of connections with zero gain.

Why not? The engine never iterates over them. They consume 16 bytes
each (drop the "next" pointer, BTW). They are a useful holder for
information, used by the Plugins both when writing to buffers and
when deciding how they are connected (for graph sorting).

All the engine does in its process() call (made by a Driver) is:

    foreach plugin in sorted_execution_plugin_list {
            foreach port in plugin { port->prepare (); }
            plugin->process ()
    }

The Connection objects are "silent" partners.
    
>the gain is being set to 0.0. That way a huge 4096-knob GUI matrix
>could be implemented in a simplistic way without impacting on the
>efficiency of the engine.

I don't believe that any number of connections will have any impact
other than affecting the memory footprint because of gain lookups
during port data mixing. If gain is supported in this way, then
there always needs to be this lookup, and it won't ever be
efficient cache-wise.

>This is a good reason why we need to have gains on our connections
>within the engine - the engine needs to be the one doing the mixing,
>in order to have maximum flexibility to optimise execution.

Nicely worded, and much more concise than I could do.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed May 23 2001 - 18:46:19 EEST