linuxaudio.org

On Sat, 2012-06-02 at 11:37 +0200, Tim Goetze wrote:

quoted text
> [David Robillard]

>

> >On Fri, 2012-06-01 at 20:22 -0400, David Robillard wrote:

> >[...]

> >> I am attempting to farm

> >> precisely one piece of information: whether or not the above callback

> >> can adequately express any reasonable block length situation; i.e.

> >> whether or not any plugin could know "yes, I can run" or "no, my

> >> requirements to run are not met".

> >

> >Also, I suppose, if restrictions need to be dynamic, or if static will

> >suffice.

> >

> >Specifying exact minimums and/or multiples seems pretty esoteric and of

> >dubious benefit to me.  Doing so dynamically even more so...

>

> If you will allow me to go back and question the rationale for a bit:

>

> Consider a simplistic convolution plugin designed around a fixed

> FFT-dictated block size.  Obviously somebody has to decouple this

> fixed size from whatever is factually mandated by the audio hardware

> or used by a freewheeling host's main audio loop.  As long as the host

> isn't *required* to implement this decoupling, our plugin *must* do it

> itself and work with whatever the host asks it to process, be it 1,

> 23, or 16384 frames at a time.

>

> As a plugin author, I consider all assumptions or guarantees about

> the block size useless unless the plugin can tell the host exactly

> what it wants, and get it everytime (and I'm not even sure it would be

> worth it).

LV2's feature mechanism is specifically designed so plugins can

*require* features if they need to.  A plugin that requires a feature

will not be instantiated if it is not available.
This lets us hammer out functionality without having to fight about what

everyone *has* to implement.  Essentially everything is as you say,

except *you* get to decide what you require, there is no central

authority (me) mandating what everyone must require.
There are some situations where a given feature (like power of 2 block

length) are sensible/possible, and some where they are not.  In this

case, for example, a restricted block length is required for latency

free convolution plugins, period.
So, the API should support this.  That does not imply it will/can/should

be available in every scenario.  If you don't want to require it -

don't.  If you want to do convolution in hosts that can't provide it,

you have to add latency.
LV2 is not in the business of crippling *everything* because *something*

can't do it.  The decisions about whether to make use of or implement

something like this, as you described, are inherent to the problem, and

depend on the situation.  The API should make it possible to do what you

want - not get in the way.
Cheers,
-dr
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev