Re: [linux-audio-dev] LADSPA 2

From: Lars Luthman <larsl@email-addr-hidden>
Date: Sun Apr 23 2006 - 18:16:11 EEST

On Sun, 2006-04-23 at 17:04 +0200, Florian Schmidt wrote:
> On Sun, 23 Apr 2006 13:39:52 +0100
> Steve Harris <S.W.Harris@email-addr-hidden> wrote:
>
> > On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian Schmidt wrote:
> > > 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.
> >
> > Thats a new feature. It'll have to wait til after 2.0 as far as I'm
> > concerned.
>
> I tend to disagree as it is kinda orthogonal to the other proposed
> changes. What time other than a major version change is better to add
> such a feature?
>
> Aw hell, i'll try to get this into DSSI 2 then ;)

Couldn't it be done as an extension using the "features" parameter to
the instantiation function? If the host supports fixed buffer sizes it
can pass "FIXEDSIZE" or something in the features array, and the plugin
can add some sort of flag in the TTL file that says that it wants to be
called with a fixed buffer size. No need to add it explicitly in the
LADSPA2 specification.

Then, when the plugin sees that the host has the "FIXEDSIZE" feature, it
will know that the buffer size will always be the same. Hosts that don't
support this extension will ignore the flag in the TTL file and will not
pass the "FIXEDSIZE" feature to the instantiation function, and the
plugin can then either return NULL from that function, or switch
automatically to less efficient code that does not need a fixed buffer
size.

-- 
Lars Luthman
PGP key:     http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A  E1B3 4371 4650 04C7 7E2E

Received on Sun Apr 23 20:15:06 2006

This archive was generated by hypermail 2.1.8 : Sun Apr 23 2006 - 20:15:06 EEST