Re: [linux-audio-dev] PTAF link and comments

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

Subject: Re: [linux-audio-dev] PTAF link and comments
From: Steve Harris (S.W.Harris@ecs.soton.ac.uk)
Date: Tue Feb 04 2003 - 09:54:30 EET


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.

Plugins should also be free to use the range how they like.
 
> > > * Tail size. (Can be unknown!)
> >
> > in my notes, in a different way, but this may just be simpler
>
> Yeah... It's guessing and various hacks anyway for many plugins, so
> you can't require much, and I don't think there's much point in going
> below block granularity. It gets hairy, and I think few hosts and
> plugins will make full use of it even when it's theoretically
> possible. Just too much work, and it actually *costs* cycles when you
> need them most: when all plugins are running full throttle.

Useful though. And most plugins can estimate it pretty accuratly, it will
be used for post-roll. Ardour could use this, for example.
 
> 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, 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.
 
> > 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.
 
> > 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!
 
> 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.
 
> 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.

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

- Steve


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

This archive was generated by hypermail 2b28 : Tue Feb 04 2003 - 09:58:18 EET