Efficient real time spectrum graphing techniques?

DSP, Plug-in and Host development discussion.
Fender19
KVRist
282 posts since 30 Aug, 2012

Post Sun Aug 11, 2019 4:36 pm

A lot of plugins these days - especially EQ plugins - include real time spectrum graphs in their display. Many of these plugins claim to be "light on resources" yet, AFAIK, FFTs are the only way to generate spectrum data - and FFTs are NOT light on resources!

So, are there less computationally-intensive means being used to generate these spectrum graphs?

xoxos
Mr Entertainment
12138 posts since 30 Apr, 2002 from i might peeramid

Re: Efficient real time spectrum graphing techniques?

Post Sun Aug 11, 2019 4:47 pm

?? all of my audio dsp has been done on single cores. i use the fft from dspguide.com, with some obvious optimisation. its not as fast as the common libraries for sure. but eg. for a 2x overlap, without much else going on i'd expect it to stay under 6% cpu. and of course for a graphic display the rate can be dropped some. i threw a 256 window display on the last standalone generator i coded, iirc it just captured a window every 16th note and so was basically invisible on cpu.
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

Fender19
KVRist
282 posts since 30 Aug, 2012

Re: Efficient real time spectrum graphing techniques?

Post Sun Aug 11, 2019 5:02 pm

xoxos wrote:
Sun Aug 11, 2019 4:47 pm
?? all of my audio dsp has been done on single cores. i use the fft from dspguide.com, with some obvious optimisation. its not as fast as the common libraries for sure. but eg. for a 2x overlap, without much else going on i'd expect it to stay under 6% cpu. and of course for a graphic display the rate can be dropped some. i threw a 256 window display on the last standalone generator i coded, iirc it just captured a window every 16th note and so was basically invisible on cpu.
I guess I am thinking of processors like noise reduction where FFT heavily taxes CPUs. Perhaps it's all the computation before and after the FFT/iFFT conversions that causes that load.

So, keep the sample rate and resolution low and FFTs are not a problem for graphing. Will check out dspguide.com Thanx! :tu:

User avatar
vortico
KVRist
283 posts since 19 Jul, 2008

Re: Efficient real time spectrum graphing techniques?

Post Tue Aug 13, 2019 8:44 am

>FFTs are NOT light on resources

FFTs are very light on resources. For `float[256]` blocks, the computation of an FFT is <1ns per sample, which is faster than accessing the elements in memory, so it's essentially a free computation.
VCV Rack open-source virtual modular synthesizer

mystran
KVRAF
5325 posts since 12 Feb, 2006 from Helsinki, Finland

Re: Efficient real time spectrum graphing techniques?

Post Tue Aug 13, 2019 2:54 pm

Fender19 wrote:
Sun Aug 11, 2019 4:36 pm
A lot of plugins these days - especially EQ plugins - include real time spectrum graphs in their display. Many of these plugins claim to be "light on resources" yet, AFAIK, FFTs are the only way to generate spectrum data - and FFTs are NOT light on resources!

So, are there less computationally-intensive means being used to generate these spectrum graphs?
Another way to generate a spectrum graph is to use a bank of band-pass filters, but using an FFT is generally faster.
If you'd like Signaldust to return, please ask Katinka Tuisku to resign.

mystran
KVRAF
5325 posts since 12 Feb, 2006 from Helsinki, Finland

Re: Efficient real time spectrum graphing techniques?

Post Tue Aug 13, 2019 2:56 pm

vortico wrote:
Tue Aug 13, 2019 8:44 am
>FFTs are NOT light on resources

FFTs are very light on resources. For `float[256]` blocks, the computation of an FFT is <1ns per sample, which is faster than accessing the elements in memory, so it's essentially a free computation.
Well.. for good resolution at low frequencies you might want a lot longer FFTs (eg. 4k or more) and then you end up with the problem that you have to overlap them to get a decent visual framerate..

But even then, drawing the resulting data is usually a whole lot more expensive than the FFTs. :)
If you'd like Signaldust to return, please ask Katinka Tuisku to resign.

AnalogGuy1
KVRian
574 posts since 6 Mar, 2005 from USA

Re: Efficient real time spectrum graphing techniques?

Post Tue Aug 13, 2019 3:42 pm

If you don't care about phase, a way to make FFT decomposition even faster is to pre-allocate memory (that's a 2^N size) and fill it up with incoming samples in a ring fashion. Then "unfold" the FFT computation for this specific length so there's no loops (easier to write code that writes code to remove all the loops). This machine-written code that's specific to your loop length will be ugly as anything, but I've found it runs much, much faster than looped code written for the general-length case. If you really need that phase, you could recover it since the loop will add a linear phase proportional to the offset in the loop of your current sample.

On laptops that were out in 2006 I could do a 32k FFT on streaming data with a 30 fps screen update and still only use 4% of the processor core.

Fender19
KVRist
282 posts since 30 Aug, 2012

Re: Efficient real time spectrum graphing techniques?

Post Tue Aug 13, 2019 8:06 pm

vortico wrote:
Tue Aug 13, 2019 8:44 am
>FFTs are NOT light on resources

FFTs are very light on resources. For `float[256]` blocks, the computation of an FFT is <1ns per sample, which is faster than accessing the elements in memory, so it's essentially a free computation.
4-6% CPU usage that some are stating here is not “light” IMO. Try to use a dozen plugins like that in a typical mixing scenario and see what happens!

What do you mean by “processes a sample in <1nS”? On what speed of machine, with what overlap, etc.?

Can you clarify?

matt42
KVRian
1121 posts since 9 Jan, 2006

Re: Efficient real time spectrum graphing techniques?

Post Tue Aug 13, 2019 8:49 pm

Fender19 wrote:
Tue Aug 13, 2019 8:06 pm
4-6% CPU usage that some are stating here is not “light” IMO. Try to use a dozen plugins like that in a typical mixing scenario and see what happens!
Perhaps, but I wouldn't keep a dozen plugins open all displaying spectral graphs at the same time and, presumably, your plugin will only perform these calculations while the interface is open.

User avatar
vortico
KVRist
283 posts since 19 Jul, 2008

Re: Efficient real time spectrum graphing techniques?

Post Tue Aug 13, 2019 10:28 pm

4-6% CPU usage is definitely wrong. I don't know what FFT implementation they're using, but you should be getting <1ns/sample with FFT block sizes ranging from 2^5 to 2^18 with anything in the last 10 years that supports AVX. That'd be around 0.005% CPU at 44.1kHz.
VCV Rack open-source virtual modular synthesizer

mystran
KVRAF
5325 posts since 12 Feb, 2006 from Helsinki, Finland

Re: Efficient real time spectrum graphing techniques?

Post Wed Aug 14, 2019 1:24 am

AnalogGuy1 wrote:
Tue Aug 13, 2019 3:42 pm
Then "unfold" the FFT computation for this specific length so there's no loops (easier to write code that writes code to remove all the loops). This machine-written code that's specific to your loop length will be ugly as anything, but I've found it runs much, much faster than looped code written for the general-length case.
Something that should probably be mentioned is that a typical text-book radix-2 can easily be a factor of 100 (or more) slower than a properly optimised FFT library. Optimising twiddle computations (and using constant lookups for small blocks) is the first step. Completely unfolding (use split-radix) tends to only be profitable for small (sub-)blocks (eg. 64 or less). As the blocks get larger, you tend to become more and more memory bound and you should basically run the largest radix (probably either 4 or 8 in practice) you can fit into registers, then stride blocks as large as possible without trashing L1 cache.

But seriously, unless you want to spend a ton of time learning about all the possible optimisations and then tuning it, you should really just use some existing FFT library.
If you'd like Signaldust to return, please ask Katinka Tuisku to resign.

quikquak
KVRian
548 posts since 6 Aug, 2005 from England

Re: Efficient real time spectrum graphing techniques?

Post Wed Aug 14, 2019 2:38 am

At first I thought 'Fender19' was thinking they need to be done every sample!

mystran
KVRAF
5325 posts since 12 Feb, 2006 from Helsinki, Finland

Re: Efficient real time spectrum graphing techniques?

Post Wed Aug 14, 2019 3:26 am

Another tip: if you don't need the spectrum data in DSP code (eg. conventional EQ where it's only used for visual display), then you can simply send the samples as-is into a wait-free queue and do all the FFT computations in the GUI thread. This way the audio processing cost is practically zero and even if you start running low on CPU, you'll only take a performance hit with GUI framerates rather than glitching the audio.
If you'd like Signaldust to return, please ask Katinka Tuisku to resign.

User avatar
DJ Warmonger
KVRAF
3148 posts since 7 Jun, 2012 from Warsaw

Re: Efficient real time spectrum graphing techniques?

Post Wed Aug 14, 2019 3:35 am

matt42 wrote:
Tue Aug 13, 2019 8:49 pm
Fender19 wrote:
Tue Aug 13, 2019 8:06 pm
4-6% CPU usage that some are stating here is not “light” IMO. Try to use a dozen plugins like that in a typical mixing scenario and see what happens!
Perhaps, but I wouldn't keep a dozen plugins open all displaying spectral graphs at the same time and, presumably, your plugin will only perform these calculations while the interface is open.
Yep. It is also important to run spectrum in separate thread so it doesn't block audio stream and slow down audio buffer processing.
http://djwarmonger.wordpress.com/
Tricky-Loops wrote: (...)someone like Armin van Buuren who claims to make a track in half an hour and all his songs sound somewhat boring(...)

Fender19
KVRist
282 posts since 30 Aug, 2012

Re: Efficient real time spectrum graphing techniques?

Post Wed Aug 14, 2019 7:27 am

quikquak wrote:
Wed Aug 14, 2019 2:38 am
At first I thought 'Fender19' was thinking they need to be done every sample!
No - I got past THAT misunderstanding long ago when I needed to run some big FIR filters. Using FFT means was “light years” faster.

Return to “DSP and Plug-in Development”