Subject: [linux-audio-dev] matrix routing
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri May 18 2001 - 20:18:04 EEST
>> well, the problem is that it then requires that very little
>> sharing of buffers by ports can go on. this is not a consequence of
>> the matrix model, though, but of having multiple destinations with
>> independent gains.
>
>OK, yes, I was forgetting that you could reuse buffers.
well, its not as bad as I indicated in another message. i realized (i
think!) that if we require a plugin to either do in-place processing,
or to get a scratch buffer from the engine if it can't, then an "input
port" is really just a "pointer". There's no memory associated with
it. When we need to get data "from the input port", its either not
connected, so there's no data, or it is connected, and the data source
is some (other) output port.
you know what else is good here? all the plugins can use the "run()"
(assignment) approach when processing data in their output buffer, but
the engine (not the plugin) can optimize moving data from the input
sources into the output buffers. for example:
the input port is not connected: memset (buf, 0, n);
the input port is connected to one other port: memcpy (buf, obuf, n);
the input port is connected to N other ports:
memcpy (buf, obuf[0], n);
for i in 1..N { add_buffers (buf, obuf[i], n); }
the plugin's don't have to worry about it in any way except to ensure,
as i mentioned that they can either do in-place processing or use a
scratch buffer if they can't.
>the 1 block latency is going to be unpleasant. The Nord Modular doesn't
>sort, but its processing blocks are very small, a few 96k samples.
heh. well, i do a weak-order sort. that is, if the graph contains any
feedback loops, it makes no attempts to solve them, since it can't be
done. if it doesn't contain any feedback loops, its fine.
and note that we sort at the plugin level, not the port level. thus,
there may be the appearance of a feedback loop:
pluginA uses the output of pluginB
pluginB uses the output of pluginA
but in reality, there is none:
pluginA, port 1 uses the output of pluginB, port 1
pluginB, port 2 uses the output of pluginA, port 2
where the contents of port1 and port2 have no relationship to each other.
in the above case, i would just run the most-recently created of plugin{A,B}
first, which is as optimal as the other way around.
this way, the loop you wrote gets a partial execution when just before
we execute each plugin, affecting only the ins/outs that involve that
plugin. sound OK?
--p
This archive was generated by hypermail 2b28 : Fri May 18 2001 - 20:51:03 EEST