Re: [LAD] Plugin buffer size restrictions

On Sat, 2012-05-26 at 20:05 +0000, Fons Adriaensen wrote:
> On Sat, May 26, 2012 at 02:23:52PM -0400, David Robillard wrote:
[...]
> Which leads to an interesting observation: you extension
> actually negates part of the core specs. So that is allowed ?

Sure it is. In this case, it's not even weird, if we do this now it
will look EXACTLY the same as if we did it from day one. It's a
textbook case of what the feature mechanism was designed to do, and not
weird or unnatural at all.

In LV2, stuff like this is done via "features". A feature is either
optionally supported, or required, by a plugin. In code, the host
passes a struct to instantiate for each supported feature which may
contain whatever (in this case, probably a get_buffer_size() function
and so on).

The host may not instantiate a plugin if it *requires* a feature it can
not provide. So, in this case, if the plugin requires e.g. a power of 2
buffer size, and the host can't provide that, well.. it can't provide
that and the plugin can't be used. This isn't crazy decentralized
metadata pipe-dream stuff, it's the way the API would be made from day
one anyway; extremely straightforward basic C stuff.

Because of what "required" means, you can do pretty much literally
anything with a required feature. You could define a feature where the
host must fetch the fifteenth byte from http://linuxaudio.org and pass
that to instantiate if you wanted to. It's crazy, and *requiring* that
feature surely means your plugin isn't going to work almost anywhere,
but that's fine.

In this case, however, it's not crazy at all. It's the most natural
thing in the world.

Here, notice a plugin not working in the host is *inherent*. This is
why LV2 folks generally don't consider this a "problem" - it isn't one.
If the host literally *can't* provide a given feature (e.g. fixed buffer
size) and the plugin *requires* it to function at all, well, clearly the
plugin can't work in that host. LV2 merely provides a mechanism to
express such things. The decision of whether to do them is inherent.

It is not my job, or your job, to tell plugin and host authors what they
can and can not do. Ad hoc extensions are where innovation happens,
where solutions get sorted out *before* they become part of the main
spec. You can't sort them out without actually implementing them.
Software simply does not work that way. Ever.

Different host authors have different opinions about conservatism and
compatibility and such. This is fine and good and expected and natural.
It will all work out eventually. You've been around here long enough to
know everything ain't happening tomorrow regardless :)

tl;dr: If buffer size restrictions are the way to go, then let's go that
way. It's just that simple.

> > You criticize LV2 for having control ports, but then say an alternative
> > is impossible because it would be invasive? This does not make sense.
>
> Not for having control ports. For encouraging (almost mandating -
> there is no alternative in the core spec) a way to provide control
> values at arbitrary points by manipulating the nframes of a process()
> call. There is a world of difference between
>
> 1. telling a plugin that at N frames from the current position the
> parameter P should have value V, and
> 2. doing the same, while also requiring that the plugin outputs
> N frames at that time.
>
> My argumentation is that doing (2) is a bad idea, and even more so if
> you consider that (1) is a silly thing to in the first place, at least
> for the usual audio processing tasks such as EQ, dynamics, and most
> effects. The exception is synthesis modules of course, but those should
> have a dedicated mechanism for it anyway, or accept audio rate controls.

This is a bit difficult to decipher. You are saying you think
block-accurate controls at a given fixed minimum size are good enough?

That's just LADSPA with a simple restriction on sample_count parameter.

However, making "synthesis modules" an exception is kind of pointless
over-classification. Either a sample accurate control mechanism is
required, or it isn't. There is no hard distinction between "synthesis
modules" and other things anyway, it is not a useful (false) dichotomy.

> The full report included a detailed anaysis of why (1) is a bad
> idea in most cases (with the exception of synthesis modules). It
> is because it makes it almost impossible for the plugin code to
> compute good parameter trajectories. A well-designed EQ, effect,
> compressor, etc. should actually *ignore* attempts to control its
> internals in such a way. So there was never any need to allow
> arbitrary nframes values. The correct thing to do would be to
> remove that from the core spec, and provide an extension for
> finer-grained 'sample accurate' control.

It's odd to speak of this like there has been some active decision to
"allow" arbitrary nframes values. It's more accurate to say that
basically nothing has been said about this thus far. It is simply an
absence of well-defined restriction because nobody has defined them yet.

If you're content with LADSPA style controls with just a restriction on
block size, that's trivial. I don't really see why you've made such a
big deal about it. There's plenty of questions raised by a sample
accurate control port (mainly whether to MUX the controls to a single
event buffer or not), but no questions about that. From a spec POV,
it's easy.

It'd have been solved and implemented long long ago if it was brought up
in useful channels and not weird cloak and dagger reports...

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun May 27 00:15:10 2012