[LAD] Plugin buffer size restrictions
d at drobilla.net
Sat Jun 2 00:22:37 UTC 2012
On Fri, 2012-06-01 at 22:56 +0000, Fons Adriaensen wrote:
> On Fri, Jun 01, 2012 at 06:42:01PM -0400, David Robillard wrote:
> > On Fri, 2012-06-01 at 22:22 +0000, Fons Adriaensen wrote:
> > > On Fri, Jun 01, 2012 at 06:09:06PM -0400, David Robillard wrote:
> > >
> > > > LV2_Buf_Size_Status
> > > > get_block_length(LV2_Buf_Size_Buf_Feature_Handle handle,
> > > > uint32_t* min,
> > > > uint32_t* max,
> > > > uint32_t* multiple_of,
> > > > uint32_t* power_of);
> > > >
> > >
> > >
> > > > This callback just describes reality to the plugin at instantiation
> > > > time.
> > >
> > > That 'to the plugin' confuses me - isn't this supposed to be
> > > the plugin telling the host what it (the plugin) needs ?
> > This is a host-provided callback which the plugin can use at
> > instantiation time to figure out the block length characteristics,
> > whatever they may be.
> (Maybe it's just too late for me to grok this...)
> So it's the plugin asking the host what it can expect ?
> Isn't the LV2 way to do this via features (i.e. the plugin
> checking which features the host provides) ?
Yes, this callback is in a feature struct. Essentially "feature" just
means "thing provided by the host".
Restrictions would also be features, but nevermind that. Regardless of
restrictions, plugins need to know the actual situation (for example,
right now I need to know max, and have no restrictions). It decomposes
Not mentioning any of that was no mistake; 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".
There is no point confusing the thread with restrictions since that part
follows directly from the above.
Also, I said something stupid about constant size earlier. Of course,
constant can be expressed with min == max.
 Poor choice in terminology here, it turns out
 I know this stupid list and how to extract useful information from
it and ignore the rest ;)
More information about the Linux-audio-dev