Re: [linux-audio-dev] XAP spec & PTAF comments [merge]

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] XAP spec & PTAF comments [merge]
From: Tim Hockin (thockin@hockin.org)
Date: Sat Feb 08 2003 - 03:17:51 EET


> > > something out... It just seems to me that plugins have a better
> > > idea how to clamp - and they can quite often use constant limits
> > > as well, I guess.
> >
> > I'm fine with this. If the plugin can constrian the inputs itseelf,
> > it seems reasonable not to have explict host support. We know it
> > works, and its Simple(TM)
>
> Yeah. It's always a good idea to consider alternatives, I guess we
> haven't seen any sensible ones yet...

Assuming we really want to allow soft-limits (which I just don't get), we
can just say that if you want a hardlimit, constrain it internally.

I'm all for optimizations, but really, this is a MICRO MICRO MICRO MICRO
optimization. SOMEONE SOMEWHERE is going to do a conditional and constrain.
Be it the host or the plugin.

Let's just say that all ranges are suggestions, and if it matters, it is the
plugin's problem. If we later find this to be a big problem, we'll deal
with it. Fair?

> > > I do see your point, but I'm not certain whether or not this
> > > optimization is really useless for normal "one song at a time"
> > > use. Some real life test data would be really interesting...
>
> Yeah, that's one of the reasons why I can't quite make up my mind on
> this. This feature is not for free, so it has to be seriously
> motivated.

I think it can come almost free. Plugins that don't optimize, do nothing.
Plugins that want to optimize do an extra flag check. Not too hard.

> Besides, if you have seriously heavy plugins in combination with this
> "a few effects at a time" behavior, the host could probably optimize
> this a bit without plugins explicitly supporting it. It means the
> host has to test buffers and figure out a clean way of activating and
> deactivating plugins without side effects, but if the plugins, or
> whole sub nets of plugins can be disabled, it's still a big win.
> ...and doesn't require any API support whatsoever, apart from the
> (de)activation stuff, which is needed anyway.

This was more or less what I originally proposed. If a plugin can indicate
that it will not do anything unless more (non-zero) signal turns up, it can
be virtually removed from the tree. Except it still needs to run() for
events.

On thinking of it, I think Silent-per-buffer flags are better.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 03:27:36 EET