Re: [LAD] ANN: convoLV2 0.2

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:
>
> > 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.

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.

> 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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev