Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Tue Feb 04 2003 - 17:53:15 EET
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 ---
This archive was generated by hypermail 2b28 : Tue Feb 04 2003 - 17:54:01 EET