Subject: Re: [linux-audio-dev] XAP spec & PTAF comments [merge]
From: David Olofson (david@olofson.net)
Date: Sat Feb 08 2003 - 04:06:40 EET
On Saturday 08 February 2003 02.17, Tim Hockin wrote:
[...]
> 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.
Yeah.
As to soft limits, I think the main point is to relieve the plugin
author of the task of figuring out the absolute minimum and maximum
control values that could possibly generate any interesting results,
so he/she doesn't have to release a modified plugin under a different
major version number later on, just to extent some control ranges.
If you can't decide on the "useful" range, just throw something
reasonable into the range hints, and clamp to some bigger range that
you know is technically safe for the algorithm. If users want to look
for cool effects outside the "official" ranges, they can, and
although plugins might produce evil noises (which some actually might
find useful), they won't crash or anything like that.
> 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.
Yes. The only exceptions would be when you have a hard limited output
that's within the range of a hard limited input, and when you have
prerecorded data. However, the latter case only applies if you assume
that recorded data will be destructively processed whenever you
connect something. *heh*
> 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?
Yeah. Works for LADSPA, so it can't be *that* bad.
> > > > 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.
Right, but you have to put the flag somewhere. If there's a nice place
for it,
>
> > 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.
Yeah, you're right... Effects *generally* don't start making sound
just becaues you change some parameter, though - but that's the only
way this could work at all.
You need an explicit "run without processing audio" mode for this.
> On thinking of it, I think Silent-per-buffer flags are better.
Yes. The alternative would be some other, closely related but much
less obvious feature... And then we might as well do it properly. Or
not at all.
I think we have to think about the implications. Let's look att all
combinations for starters:
0) Silent buffers; host: NO, plugin: NO
No problem. No one will check the flags,
and all buffers will contain valid data.
The host SDK would clear the "silent"
flags when initializing the buffer
structs.
1) Silent buffers; host: NO, plugin: YES
This will not work, since a plugin with
silence support may leave garbage in
silent output buffers. The host must
check and clear such buffers before
they are fed to plugins w/o silence
support.
2) Silent buffers; host: YES, plugin: NO
No problem. There will be no silence for
the host to deal with.
3) Silent buffers; host: YES, plugin: YES
No problem. Whenever a plugin without
silence support is to be called, the
host will check and clear any silent
buffers on the plugin's inputs. The
host will also reset the "silent"
flags of all outputs from the plugins,
since the plugin will always generate
valid output, but not touch the flags.
Now, there is a problem here: If you have a chain of plugins, and some
of them don't support silence, these will screw things up for the
silence aware plugins. However, if we apply silence detectors on the
outputs of plugins w/o silence support whenever they're sending to
plugins *with* silence support, things will work fine.
Any other aspects?
And of course, regardless of how complicated or simple this is, it has
to be sufficiently motivated.
One thing I haven't really considered before (in the DAW context), is
that any CPU time you save in the DSP thread reduces the risk of
drop-outs in a "firm" or soft real time system, and maybe more
importantly (to people with real operating systems ;-), it is extra
CPU power for disk butlers and other high latency background
processes.
I don't think this is insignificant, *especially* not if XAP is
supposed to go anywhere outside Linux/lowlatency or other
"practically hard real time" platforms.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 04:06:13 EET