sylwekkominek/SpectrumAnalyzer was created because, since childhood, I enjoyed watching the “jumping bars” moving in sync with music on my Technics EC-EH550 stereo system. Unfortunately, modern audio equipment rarely includes built-in spectrum analyzers. While many visualizer apps exist online, they typically lack flexibility and become repetitive due to limited customization options. The app is open source and runs on both Windows and Ubuntu. You can also create your own themes by copying the contents of getAdvancedColorSettings() and getBackgroundColorSettings() functions from config.py into ChatGPT and saying: “Create something unique.”
The core of this project is the AudioSpectrumAnalyzer class, which manages the entire process using several parallel threads for real-time performance:
samplesUpdater – collects audio data using PortAudio (or a custom signal from audioConfig.py) and places it into a queue.
fftCalculator – applies a window function and computes the FFT using the FFTW library. It uses Welch’s method with overlapping to increase the number of frames per second (FPS), which is crucial for smooth animation.
processing – processes FFT data, applies gain correction, peak hold, averaging and smoothing.
drafter – converts dBFS levels into vertex offsets sent to the GPU to render the bars.
flowController – monitors the current FPS and dynamically adjusts the amount of overlapping used in Welch’s method. This adaptive algorithm automatically increases or decreases overlap depending on hardware performance and the desired FPS set in config.py.
Why Welch’s method and overlapping are necessary
To accurately detect low frequencies (such as 20–50 Hz) at the commonly used sampling rate of 44,100 Hz, the application processes audio in chunks of 4096 samples.
This results in a frequency resolution of approximately 10.77 Hz for the FFT (calculated by dividing 44,100 by 4096). In simpler terms, the FFT measures energy in discrete frequency steps of about 10.77 Hz.
Processing 4096 samples at once means a new analysis frame is created roughly every 4096 ÷ 44,100 ≈ 93 milliseconds, which equals about 11 frames per second (FPS) — too low for smooth real-time visualization.
To improve responsiveness without sacrificing low-frequency resolution, the application uses overlapping windows based on Welch’s method. Instead of waiting for a completely new block of 4096 samples, it shifts the analysis window forward by a smaller step (for example, 512 or 1024 samples), reusing much of the previous data. This significantly increases the number of analysis frames per second — allowing for smooth 60 FPS animation while still analyzing long enough segments to preserve detail in the bass range.
A more detailed description is available here:
Top comments (0)