If it is purely for graphic display, the interesting aspect coding-wise
will be timing, so that the display coincides closely enough with the
audio it represents. In this regard, the update rate for a running
display rarely needs to be more than 60 fps, and can often be slower -
so you would only need to compute FFTs at those intervals (e.g.
triggered by a timer and reconciled with your main audio buffer), not
at the higher analysis frame rates associated with FFT overlapping.
Richard Dobson
On 11/06/2015 16:18, Phil Burk wrote:
Hello Connor,
If you just wanted to do a quick FFT and then using the spectrum to control
synthesis, then I would recommend staying in the callback. If you are doing
overlap-add then set framesPerBuffer to half your window size and combine
the current buffer with the previous buffer to feed into the FTT.
But if you are using the FFT to do complex analysis, or to drive a graphics
display, then that is probably too much for the callback. In that case just
set the callback pointer to NULL and use Pa_ReadStream() with a large
buffer size.
http://portaudio.com/docs/v19-doxydocs/portaudio_8h.html#a0b62d4b74b5d3d88368e9e4c0b8b2dc7
This decouples your code from the main audio processing. Then you can do
almost anything, including writing files or generating graphics displays.
You will probably need to create a separate thread that does the read and
the FFT.
Phil Burk
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
