#fft #spectrum #audio #dsp #frequencies

no-std spectrum-analyzer

A simple and fast no_std library to get the frequency spectrum of a digital signal (e.g. audio) using FFT. It follows the KISS principle and consists of simple building blocks/optional features.

21 releases (5 stable)

new 1.1.2 Sep 14, 2021
1.1.1 Sep 12, 2021
0.5.2 Apr 19, 2021
0.4.6 Apr 7, 2021
0.1.1 Mar 13, 2021

#22 in No standard library

Download history 4/week @ 2021-05-30 21/week @ 2021-06-06 7/week @ 2021-06-13 2/week @ 2021-06-20 6/week @ 2021-06-27 14/week @ 2021-07-04 5/week @ 2021-07-11 21/week @ 2021-07-18 23/week @ 2021-07-25 39/week @ 2021-08-01 5/week @ 2021-08-08 37/week @ 2021-08-15 6/week @ 2021-08-22 2/week @ 2021-08-29 19/week @ 2021-09-05 85/week @ 2021-09-12

78 downloads per month
Used in 3 crates

MIT license

280KB
2K SLoC

Rust: library for frequency spectrum analysis using FFT

A simple and fast no_std library to get the frequency spectrum of a digital signal (e.g. audio) using FFT. It follows the KISS principle and consists of simple building blocks/optional features. In short, this is a convenient wrapper around several FFT implementations which you can choose from during compilation time via Cargo features.

I'm not an expert on digital signal processing. Code contributions are highly welcome! 🙂

The MSRV (minimum supported Rust version) is 1.52.1 stable. If you run tests, it is 1.55.0 stable since

I want to understand how FFT can be used to get a spectrum

Please see file /EDUCATIONAL.md.

How to use (including no_std-environments)

Most tips and comments are located inside the code, so please check out the repository on Github! Anyway, the most basic usage looks like this:

FFT implementation as compile time configuration via Cargo features

By default this crate uses the real-module from the great microfft-crate. It's the fastest implementation and as of version v0.5.0 there should be no valid reason why you should ever change this. The multiple features are there mainly for educational reasons and to support me while programming/testing.

Cargo.toml

# ONLY NEEDED FOR `no_std`-builds!
# fixes `no_std` build problems caused by wrong feature resolution of Cargo
# This works since Rust 1.51 (stable)
resolver = "2"

# by default feature "microfft-real" is used
[dependencies]
spectrum-analyzer = "<latest version, see crates.io>"

# or if you need another feature (FFT implementation)
[dependencies.spectrum-analyzer]
default-features = false # important! only one feature at a time works!
version = "<latest version, see crates.io>"
features = ["rustfft-complex"] # or on of the other features

your_binary.rs

use spectrum_analyzer::{samples_fft_to_spectrum, FrequencyLimit};
use spectrum_analyzer::windows::hann_window;
use spectrum_analyzer::scaling::divide_by_N;

/// Minimal example.
fn main() {
    // YOU need to implement the samples source; get microphone input for example
    let samples: &[f32] = &[0.0, 3.14, 2.718, -1.0, -2.0, -4.0, 7.0, 6.0];
    // apply hann window for smoothing; length must be a power of 2 for the FFT
    // 2048 is a good starting point with 44100 kHz
    let hann_window = hann_window(&samples[0..8]);
    // calc spectrum
    let spectrum_hann_window = samples_fft_to_spectrum(
        // (windowed) samples
        &hann_window,
        // sampling rate
        44100,
        // optional frequency limit: e.g. only interested in frequencies 50 <= f <= 150?
        FrequencyLimit::All,
        // optional scale
        Some(&divide_by_N),
    ).unwrap();

    for (fr, fr_val) in spectrum_hann_window.data().iter() {
        println!("{}Hz => {}", fr, fr_val)
    }
}

Performance

Measurements taken on i7-1165G7 @ 2.80GHz (Single-threaded) with optimized build

Operation Time
Hann Window with 4096 samples ≈68µs
Hamming Window with 4096 samples ≈118µs
FFT (rustfft/complex) to spectrum with 4096 samples ≈170µs
FFT (microfft/real) to spectrum with 4096 samples ≈90µs
FFT (microfft/complex) to spectrum with 4096 samples ≈250µs

Example visualization

In the following example you can see a basic visualization of frequencies 0 to 4000Hz for a layered signal of sine waves of 50, 1000, and 3777Hz @ 44100Hz sampling rate. The peaks for the given frequencies are clearly visible. Each calculation was done with 2048 samples, i.e. ≈46ms of audio signal.

The noise (wrong peaks) also comes from clipping of the added sine waves!

Spectrum without window function on samples

Peaks (50, 1000, 3777 Hz) are clearly visible but also some noise. Visualization of spectrum 0-4000Hz of layered sine signal (50, 1000, 3777 Hz)) with no window function.

Spectrum with Hann window function on samples before FFT

Peaks (50, 1000, 3777 Hz) are clearly visible and Hann window reduces noise a little bit. Because this example has few noise, you don't see much difference. Visualization of spectrum 0-4000Hz of layered sine signal (50, 1000, 3777 Hz)) with Hann window function.

Spectrum with Hamming window function on samples before FFT

Peaks (50, 1000, 3777 Hz) are clearly visible and Hamming window reduces noise a little bit. Because this example has few noise, you don't see much difference. Visualization of spectrum 0-4000Hz of layered sine signal (50, 1000, 3777 Hz)) with Hamming window function.

Tips For Audio Visualization

(This is probably not 100% correct, because I'm not totally convinced by my solution/implementation.) The function FrequencySpectrum::to_log_spectrum tries to give you better suited representation for situations, when you want to analyze music. There you are most probably interested in lows, mids, and highs, but highs could be combined, i.e. 0-128hz, 128-1000hz, 8-20k. This function tries to solve this. An example visualization can be found when you execute tests. Look into ./test/out afterwards and search for the corresponding file name.

Also check out $ cargo run --release --example live-spectrum-visualization which uses your default audio input device and draws a graph to the terminal.

Building and Executing Tests

To execute tests you need the package libfreetype6-dev (on Ubuntu/Debian). This is required because not all tests are "automatic unit tests" but also tests that you need to check visually, by looking at the generated diagram of the spectrum.

Trivia / FAQ

Why f64 and no f32?

I tested f64 but the additional accuracy doesn't pay out the ~40% calculation overhead (on x86_64).

What can I do against the noise?

Apply a window function, like Hann window or Hamming window. But I'm not an expert on this.

Good resources with more information

Also check out my blog post! https://phip1611.de/2021/03/programmierung-und-skripte/frequency-spectrum-analysis-with-fft-in-rust/

Dependencies

~0.4–1MB
~18K SLoC