20 Oct
2012
20 Oct
'12
8:19 p.m.
On Sat, 2012-10-20 at 11:44 +0000, Fons Adriaensen wrote:
On Sat, Oct 20, 2012 at 12:14:29AM -0400, David
Robillard wrote:
By "zero latency" here I mean zero latency, synchronous, and strictly
hard real-time safe, i.e. no buffering and no threads whatsoever.
Also note I did not say fixed. This plugin requires a power of 2 buffer
size, not a fixed one. That is a separate feature (which also exists in
LV2 1.2.0 but there is no corresponding test plugin yet).
What I really meant was: it inherently requires restrictions, period
(perhaps not those exact ones). This is a new feature.
convoLV2 is in an early stage of development and
is not yet suitable for
users. However, it serves as a working example of an LV2 plugin with
block length restrictions, in this case:
* Maximum block length must be passed as an instantiate option
* Block length must always be a power of 2 (a required feature)
See the links in the README and on the github page for details about
these features. The first should be trivial to implement in any host,
which is highly recommended. The second may be difficult or impossible,
though it is trivial in hosts that run plugins directly on the Jack
cycle[1] or process files with fixed parameters.
Since you invited remarks:
ConvoLV2 uses libzita-convolver, but in a very inefficient way,
by restricting it to a single partition size equal to the process
block size. This is NOT necessary in order to obtain zero latency,
in fact the whole point of zita-convolver is that it can provide
zero latency even if most of the convolution is computed using
partition sizes much larger than the process block size.
This plugin is intended to provide latency-free
synchronous convolution,
which inherently requires these restrictions.
This is simply not true. A fixed, power-of-2 block size is NOT
necessary in order to obtain zero latency, not even if you use
multiple partition sizes. Supporting an arbitrary block size
(within some reasonable limits) is just a bit more complicated.
But it can be done quite efficienty using two Convproc instances
for example. Thirdly, for the use case of reverbs, the whole
latency issue is
just irrelevant. A reverb IR should not contain the direct sound
(since this will be mixed in separately), and in fact the first
10 ms or so should be silence anyway, they don't contribute to
the effect and just cause coloration. Which means you can adopt
a scheme that permits arbitrary block sizes by allowing one (Jack)
period of latency. Just remove as many samples from the start of
the IR to compensate.
The whole point of this plugin is to expose convolution at a low level
in a simple well-behaved plugin with no threads. This is obviously
desirable in some cases. It is more about being synchronous than
anything about time.
If that is not what you want, either do all the funny business at a
level above the plugin, or use a different plugin. We are not claiming
this plugin in its current form is the best way to do convolution in a
plugin in all cases.
Of course, as mentioned, the real point here is to announce a test
plugin for block length restrictions, so host authors can work on it.
Perhaps we will come to the conclusion that slightly different ones are
best in this case (e.g. any multiple of the minimum which happens to be
a power of 2), but any plugin that operates in this way will definitely
require some kind of restriction(s). Currently we have fixed, bounded,
and power of 2 (and any combination thereof), which is good enough until
proven otherwise.
-dr