Re: [linux-audio-dev] LADSPA 2

On Sat, 22 Apr 2006 10:53:58 +0100 Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote: Hi, thanks for taking the initiative on this! I would like to see a way for the host to pass its native buffer size to the plugin though. I know, this is really kind of contrary to how LADSPA is supposed to work (i.e. the run () function should be able to handle an arbitrary number of frames), but it has some serious advantages for fft-based algorithms. And i think it should be possible to merge the two approaches somewhat. A hint which the plugin could set that it needs power of two periodsizes for optimal operation would be nice, too. The host should be free to ignore this and the plugin should still work (doing what it sees fit. i.e. use non power of two fft window sizes or use double buffering again), but at least the host could notify the user that this plugin might work suboptimal. The approach of chopping up the period into smaller chunks (i.e. to update control data at non period boundaries) would still be available, but the plugin should be able to rely on the chunks being i.e. in this form: ---> time |128 |128 | | | | | | | | | | Native buffer size being 128 frames [upper row] and the lower row is how it is chopped up [as an example]. We see that all chopped up chunks add up to the native period size. This enables an fft based plugin to collect data over a whole period and do its stuff once for all these samples, without the need for extra double buffering which is a problem with current ladspa and dssi. There would be an additional requirement put on the host: It has to use a fixed underlying buffersize [optimally a power of two] even if it's not bound to do this by the hardware/soundinterface it uses. I.e. a host that does the processing freewheeling. What do you think? Flo -- Palimm Palimm! http://tapas.affenbande.org