[linux-audio-dev] PTAF link and comments

[David Olofson]

On Wednesday 05 February 2003 09.31, Sami P Perttu wrote:
[...]
> The more I'm thinking about this the more biased I am toward just
> one process() that replaces values. And an in-place-is-okay hint.
> No gains or DRY and WET controls. The host can probably reserve
> some host-global buffers for mixing, no? The cache impact wouldn't
> be big in that case. Somebody should do some actual measurements to
> find out.

Yep, although my experience with optimizing Audiality on PC133 DRAM 
machines is that it's *very* easy to end up memory bound, even if 
you're free to reuse buffers and whatnot any way you like. Memory is 
just dog slow in relation to CPU bandwidth, and 333 and 400 MHz DDR 
isn't *that* much faster, really...


> A small but seemingly annoying can of worms is the case when you
> have WET and DRY, more than one audio output, and some of the
> outputs use the same buffer. Now you have to impose that the plugin
> write its outputs in the right order to enable the host to
> calculate suitable DRY controls.

Yes, that's a good point. Didn't think of that. With just the WET 
control, there's no problem with pointing multiple outputs to the 
same buffer, but the DRY control would scale the buffer once per 
output... *heh*


> > ...pitch...
>
> I'm still having problems understanding why logarithmic frequency
> is better than linear. Doesn't it violate the principle of keeping
> plugins as simple as possible? Most plugins need linear frequency.
> How is the conversion done? Well, maybe there could be a control
> iterator that provides for it. Please tell me about your plan.

First of all, I think we have some terminology confusion here. We like 
to think of "linear pitch" as something that's linear in musical 
terms, ie 1.0/octave. Hz, rad/s and samples/period would be 
logarithmic units, from this perspective.

Anyway, the reason for not using Hz or similar in the API is that such 
units are harder to deal with, pretty much no matter what you want to 
do. The only exception is when you actually want to have some 
periodic action driven by it, ie sound. Thus, rather than using Hz in 
the API and having event processors and whatnot convert back and 
forth, we use linear pitch (1.0/octave) throughout, and leave it to 
the final stage; the synth, to convert it into whatever drives it's 
oscillators. Which, mind you, is not necessarily Hz or 
samples/period! It may well be coefficients for a resonant filter you 
need.

As to actually doing the conversion, I suppose we could throw some 
inline implementations into the plugin SDK. (One with an interpolated 
LUT and one plain FPU based - although I'm not sure the former is of 
much use on modern hardware. FPUs have faster LUTs! ;-) It's rather 
trivial stuff, but it might as well be there, given that it's pretty 
universal and makes life a bit easier, especially for DSP beginners.


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