Re: [LAD] Plugin buffer size restrictions

On Mon, 2012-05-28 at 17:08 -0400, David Robillard wrote:
[...]
> The buffer size feature is
> mostly orthogonal and simple to add; ControlPort is the thing that
> probably shouldn't have been inherited from LADSPA at all.

Back to the buffer size issue... (which is actually tangent to what this
discussion ended up being about but is sometimes useful anyway)

I am experimenting with adding the following callback. As far as
describing the block length goes, I can't imagine this not being able to
represent any reasonable situation, but just in case, I present:

/**
   Get the limits on block length.

   The values here are restrictions on the sample_count parameter of
   LV2_Descriptor::run().

   @param min Set to the minimum block length.
   @param max Set to the maximum block length, or 0 for unlimited.
   @param multiple_of Set to a number the block length will always be
   a multiple of, possibly 1 for arbitrary block lengths.
   @param power_of Set to a number the block length will always be
   a power of, or 0 if no such restriction applies.
*/
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. As far as plugins specifying requirements goes, it seems complete
to allow the plugin to specify, for each field:

1) A specific value
2) That some value must be given

The goal here is simply to be able to convey any reasonable restriction
on the block length. Whether or not people will/can actually implement
a given restriction is irrelevant.

That said, in practice, I suspect:

* max will be usually available (e.g. the Jack buffer size) and is
widely useful
* convolution plugins may require power_of 2 and perhaps min
* requirements for multiple_of, or power_of any value but 2, are
probably useless

If anyone can think of a block length restriction that can not be
described by this scheme, do tell.

Cheers,

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Jun 2 04:15:01 2012