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

[David Olofson]

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 ---