Subject: Re: [linux-audio-dev] LADSPA run() blocksize
From: David Olofson (david_AT_gardena.net)
Date: Sun Nov 19 2000 - 08:37:46 EET
On Fri, 17 Nov 2000, Paul Barton-Davis wrote:
> >> does anyone have a solution as to how a LADSPA plugin can avoid
> >> allocating any internal buffers in run(), when it needs to know the
> >> maximum value of the argument to run() and/or run_adding() ?
> >
> >I was thinking about this on my way to work, but I couldn't think of a
> >situation when you needed to know.
> >
> >You can always just chop input[] into <= buffer[] sized chunks to do your
> >processing. Might be a bit slower, but *shrug*.
>
> *shrug* !!?!! :)
>
> Its an optimization yes, but then we need optimizations like a fish
> needs water.
Indeed - an extra loop, or a pre-loop if() impacts small, simple
plugins significantly when running a net with very small buffers.
And piplines are getting *deeper* for every CPU generation, so this
is only going to get worse... (Misspredicted conditional instruction
== pipeline flush, or; the CPU has just wasted N cycles partially
executing instructions that were not meant to be executed at all. Can
be worse than a cache miss.)
> The host knows what its maximum block size is - if the i/o
> source/destination is an audio device, it will be the fragment size,
> and analogies exist for hosts doing network i/o instead. It may call
> plugins with a frame count lower than this, but it will never call
> them with a larger value.
>
> So I think we should just allow the host to call set_block_size() or
> alternatively pass the value into activate(). Then they can make sure
> their buffers are the right size and they don't have to use a double
> loop within run/run_adding. The semantics are simple:
>
> * its never called in a context considered "hard-RT", so
> using brk(2)-based or other non-deterministic functions is fine.
> * specifically, it must be called by the host *outside* the
> scope of "activate(); run(); run() ....; deactivate()".
> * the host will never call the plugin with a larger nframes
> value without first calling deactivate() and then
> set_block_size() again.
>
> What say you ?
Makes sense.
//David
.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sun Nov 19 2000 - 15:42:29 EET