Subject: RE: [linux-audio-dev] Re: A Plugin API
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ke maalis 01 2000 - 08:24:32 EST
Richard,
I disagree with the idea of not allowing input buffer = output buffer,
since as other pointed out we will waste TONS of memory bandwidth.
I hate ping-pong memory copying, and when running 10-50 plugins
simultaneously, we will deliver much worse performance than other
plugin APIs.
Plus consider the caching effect: replacing (or adding) the input buffer
data with the processed data by the plugin, will take the advantage
of less cache trashing, since the working set model is much smaller
than using 50 different buffers.
This may be the ideal case but in the average case we can save a considerable
amount of memory badwidth.
(even the first version of VST supported the add/replace method with
input buffer = output buffer)
As for your flow order concerns: I think we have to implement both methods:
one allowing input and output buffer sharing, and the other
which prohibits this explicitly allowing to connect more than one plugin
to this output buffer, so that you can avoid data copying.
In this case you will use the input buffer != output buffer method only
when there is more than one plugin connected to this output.
All other plugins (where it makes sense, line in the case of linear chains) will
run with the input buffer == output bufer method.
So that we can have the best of both worlds : speed and flexibility.
Of course the host has to process the plugins in the right order, but
that is not a big deal, since this is almost entirely determined by the
plugin connection structure. (It might become a bit more complicated
when you try do parallelize the execution flow on SMP hardware,
but that's another story).
Am I missing something ?
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST