On Mon, 2012-05-28 at 17:08 -0400, David Robillard wrote:
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
@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.
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
* convolution plugins may require power_of 2 and perhaps min
* requirements for multiple_of, or power_of any value but 2, are
If anyone can think of a block length restriction that can not be
described by this scheme, do tell.
Linux-audio-dev mailing list