[linux-audio-dev] PTAF link and comments

[David Olofson]

On Tuesday 04 February 2003 08.54, Steve Harris wrote:
> On Tue, Feb 04, 2003 at 02:11:22 +0100, David Olofson wrote:
> > PTAF uses float, subdivided in four ranges; [0,.25], [.25,.5],
> > [.5,.75] and [.75,1], where the lower two ranges are for real
> > time use, and the higher two are for off-line use.
>
> This doesn't make snese to me, off-line and wuality should be
> independent.

Yeah. Some plugins might non-deterministic (ie highly input dependent, 
and/or processing huge internal buffers without scheduling the work 
evenly over process() calls) if you use the highest quality modes, 
though - but then they'd just flip the "RT capable" hint, or maybe 
just set a warning hint.


> Plugins should also be free to use the range how they like.

How do you mean? I think 0.0 for "worst" and 1.0 for "best" would do. 
Is that too specific? ;-)


> > > > 	* Tail size. (Can be unknown!)
[...]
> Useful though. And most plugins can estimate it pretty accuratly,
> it will be used for post-roll. Ardour could use this, for example.

Yeah, I'm not arguing against the feature; just against making it more 
complex and sophisticated than most plugins and host have any use 
for. A way of saying whether you generated output (any, or per output 
buffer) during the process() call might be another.


> > Yeah, but is it really that useful? Ok, VST seems to survive with
> > the same restriction, but I'm not sure if it actually solves more
> > problems than it creates.
>
> Agreed, in practice you can connect things together if you allow
> arbitrary ranges.

Yeah. It's just a matter of who does the conversions.

If we're thinking in modular synth style terms, you'll need some form 
of gain + offset control, at the very least, to connect ins and outs 
that aren't really supposed to be connected. I don't think that's an 
issue.

As long as you connect ins and outs of the same type, they'll 
generally have compatible ranges. If not (say, your filter can't 
handle more than Nyqvist/4, but the PITCH output that controls it has 
no absolute limits), you most probably want *clamping* rather than 
scaling, so just making everything [0, 1] won't be of any help.


> > Yeah, that would be reasonable, I think. In the few cases where
> > plugins can't be in-place safe (or the author is too lazy), we
> > even have a nice, cache friendly solution: The audio buffer pool.
> > (A LIFO stack of preallocated buffers. Optimized hosts will
> > probably use one anyway, instead of fixed buffers all over the
> > net.)
>
> Hmmmm.... not convinced.

Well, it *is* an implementation thing... Hosts can just figure it all 
out beforehand, so all buffers will be in place before the net enters 
RT context - and then there would be no need for an RT safe audio 
buffer pool, of course.

Seems like a pool of audio buffers would be a nice and simple way to 
provide RT safe "dynamic" memory allocation to plugins, though, and 
that's the idea. You could (ab)use events for that, but they're 
really rather small. :-) (32 bytes, most probably.)


> > > We can standardize a wet/dry gain control pair.  But this
> > > becomes something every plugin needs to provide.  Uggh.
> >
> > It *could* be optional... The host SDK would deal with plugins
> > that don't bother to implement those controls.
>
> Not really.

Basically the same thing as plugins implementing only one of run() and 
run_adding() - you *can* emulate one with the other, although it's 
not free, of course...


> > > Well, there also needs to be a way for a plugin to wrap other
> > > formats, and change all it's metadata.  I imagined that a
> > > plugin couls tell the host that it needs to be re-examined -
> > > XAP_EV_GESTALT - or something.
> >
> > Yeah.
>
> Ugh!

Ok, how about this:

	* Hosts must provide basic information such as audio
	  sample rate, maximum buffer size, audio thread
	  characteristics (RT/offline) etc, when asking a
	  plugin lib's "plugin factory" for meta-data.

	* If this information is changed, all meta-data
	  is invalid. Hosts must ask for new meta-data before
	  trying to instantiate plugins again.


> > Yeah. run_adding() is indeed nothing but a performance hack.
> > Question is if we really need it these days. I'm not saying that
> > we'll ever have enough cycles to just waste them, but focus is
> > shifting continously. Things are getting higher level.
>
> I disagree. Its really quite expensive.

*How* expensive? I'm aware of the serious impact when it causes cache 
misses, but how much does an out[i] += in[i] * gain; stage cost? (I 
could just benchmark it, but I have only PC133 memory machines here.)


> > VST is a really rather old API, and that memory bandwidth in new
> > PCs have increased quite a bit even after LADSPA was finalized...
> > Not saying that run_adding() makes no difference to anyone *now*,
> > but in a few years, it'll probably just be a source of annoyance.
>
> Memory bandwidth has only increased a few times, CPU bandwidth has
> gone up a lot.

Yeah, and this has been going on for a good while... However, DSP code 
seems to follow the same trend; more cycles/sample, for higher 
quality and/or cooler effects. That, OTOH, does not apply to 
inherently simple/fast effects, such as basic state variable filters 
and gain/pan controls. These will always waste CPU cycles stalling on 
memory access, and will do more of it as memory bandwidth keeps 
lagging behind.

One could say that as long as we're dealing with a few large heavy 
effects and polyphonic synths and samplers in a net, this isn't much 
of an issue. In a virtual mixer with lots of little EQ plugins and 
whatnot, it might be a real performance issue. Even worse with 
anything like a modular synth.


> [cant reply to the rest, got to drive to a meeting]

Ok.


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