> Comments, opinions, anyone?
Very interesting posting, a few quick comments on what
sfront currently does, just as a reference point:
[1] Sfront tries to cope with:
> For high-order harmonics, the spike tends
> to get narrower and narrower, causing untold grief for audio processing
> algorithms operating in discrete time domain.
By detecting when the closed-form solution is in the "danger zone" for
causing numerical problems around a spike. In this case, rather than
use tables for the trig functions, it actually calls the math.h sin()
and cos() functions. This was really needed to make buzz() usable in
interesting real-time work (i.e. MIDI continuous controllers on nharm,
lowharm, or rolloff) -- without it, an unfortunate controller value
would result in "popcorn noise" where the approximation was in bad
numerical territory. With this technique, though, the linux/linbuzz
real-time example that ships with sfront 0.61 is quite playable on
my 450Mhz PIII with large polyphony supported w/o overload problems.
[2] Sfront cheats on this one:
> Specifically, the behaviour of the opcode when the ksig value of nHarm is
> not strictly positive causes real grief.
And simply recalcuates nharm once per krate nharm isn't strictly positive.
> Using a quick sine function purpose written for the buzz opcode in
> conjunction with the closed-form equation, the total a-rate execution time
> for buzz can be brought down into the 50-80 clock range.
[3] Measuring buzz() performance can be very context- and usage dependent,
but generally I see numbers in the 800-1200 nanoseconds per audio sample
point with the buzz that currently ships with sfront 0.61, on my 450Mhz PIII.
Much CPU is going to checking and fixing numerical instabilities at
various places in control space ... these checks can probably be optimized
further, but for now the focus is on finding any remaining issues and
fixing them, and that's easier to do by keeping the code somewhat
comprehensible ... dispensing with tables and use a special-purpose sin()
function would probably help a lot as well.
--jl
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:56 EST