[music-dsp] Sythesizing sines + noise in one IFFT

[Stefan Westerfeld]

   Hi!

On Mon, Oct 11, 2010 at 05:34:20PM +0200, David Olofson wrote:
> On Monday 11 October 2010, at 15.29.38, Stefan Westerfeld <stefan at space.twc.de>
> wrote:
> 
> [...]
> 
> > > In my current prototype, I'm using a 512 bin IFFT for generating a 64
> 
> > > sample window every 32'nd output sample (overlapping with a Hann window,
> 
> > > so no AM issues), which sounds good enough for a single pure sine to my
> 
> > > ears.
> 
> > >
> 
> > > That's right; I'm only actually using one 8'th of the FFT output...!
> 
> >
> 
> > From my experience I'd say that you create performance problems if you need
> 
> > larger FFT sizes than the number of output samples. The FFT is O(N log N),
> 
> > which means that if you can only use 1/8 of the FFT output, you are
> 
> > probably more than 8 times slower than an algorithm which uses every
> 
> > sample of the FFT.
> 
> That would have to depend on the cost of the extra work you need to do to get
> by with a smaller FFT, right? How many sine components can you run with 9 bins
> before that becomes more expensive than the FFT?

Well, with my codebase, adding one partial to the FFT (with 9 bins) takes about
0.23 cycles. An FFT takes about 20 cycles. If you use an 8 times as large FFT,
it will take more than 160 cycles. So 140/.23 = 608 partials are required
before using a bigger FFT might be beneficial, but thats assuming that with the
bigger approach all per-partial costs disappear. So probably 1000 partials or
so are required before a bigger FFT might be faster.

In my scenario thats unrealistic, because I only synthesize one instrument
voice per FFT, but if you combine many sounds before synthesis this case might
occur in real world scenarios.

> I'm thinking that for maximum scalability (which is what I'm after; anything
> from one sine through many thousands should be handled efficiently), one should
> probably use a set of different configurations, ranging from no FFT at all
> (time domain oscillator bank) for small numbers of components, via "many" bins
> per component, through two or three bins per component for insane numbers of
> components.

Yes, maybe you may want to implement different algorithms and pick the right
one depending on partial count for a general framework.

   Cu... Stefan
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan