About AudioNoise

AudioNoise grew out of the earlier guitar-pedal project — a physical guitar pedal built around the Raspberry Pi RP2354 microcontroller and the TAC5112 audio codec. The hardware actually worked: the TAC5112 achieved sub-millisecond ADC→DAC latency, which was the whole point.

The hardware design is now archived — pots, clicky footswitch, analog interface choices — all under review. But the digital side kept going. AudioNoise is the DSP half, running in pure simulation on desktop, no hardware required.

"While the hardware design is archived while I ponder the mysteries of life and physical user interfaces, I'm still looking at the digital effects on the side. But right now purely in a 'since it's all digital, let's simulate it and not worry about the hardware so much'."

— README.md

The two-core architecture shows up in the code: pot values use a double-buffer + sequence lock (seq / last fields on struct effect) so CPU 0 can write new pot positions atomically without CPU 1 ever reading a half-updated state.

// CPU 0 (UI): prepare pots in inactive set, flip seq bit
// CPU 1 (audio): reads active set only when seq == last
volatile unsigned int seq, last;
signed char pot_values[2][10];  // [inactive/active][pot index]

What it is

A learning exercise in digital audio processing basics. IIR biquad filters — the same math that shows up in equalizers, phasers, flangers everywhere — implemented from scratch in C, in a form that runs identically on desktop and on the RP2354.

The biquad coefficients come straight from the Audio EQ Cookbook formulas: ω₀, α = sin(ω₀)/(2Q), normalized by a₀. Nothing novel. The goal was understanding, not novelty.

What it is not

Not a cab simulator. Not a neural amp model. Not an FFT vocoder. The phaser emulates a phase-shift network using allpass filters — because that is what a phase-shift network actually is — not by training on recordings of a phaser pedal.

"Put another way: the IIR filters aren't the fancy AI 'emulate a cab' kind of a modern pedal or guitar amp. No, while they do emulate analog circuits like a phaser, they do so by emulating the effects of a RC network with just a digital all-pass filter, not by doing anything actually clever."

— README.md

Direct Form 1, not DF2

All biquads use Direct Form 1 throughout. The comment in biquad.h explains the tradeoff directly:

"Direct form 1 may need more state than the 'canonical' DF2, but gets noisy much quicker."

— audio/biquad.h

DF1 carries four state variables (two input, two output) versus DF2's two, but accumulates floating-point error more slowly on 32-bit targets. On a Cortex-M33 with single-precision FPU, that matters.

The Python visualizer was written mostly by Gemini. visualize.py reads raw s32le files via numpy memory-map, downsamples to at most 5000 plot points, and renders with matplotlib. Supports zoom (rectangle selector or scroll), keyboard navigation (arrow keys, space to reset), and side-by-side overlay of multiple raw files.

"The python visualizer tool has been basically written by vibe-coding. I know more about analog filters — and that's not saying much — than I do about python. It started out as my typical 'google and do the monkey-see-monkey-do' kind of programming, but then I cut out the middle-man — me — and just used Google Antigravity to do the audio sample visualizer."

— README.md

The repository includes BassForLinus.mp3 — a bass guitar recording used as the test signal throughout development. The Makefile converts it to input.raw (s32le at 48 kHz mono) via ffmpeg automatically when you run make output.raw.

There is also a SeymourDuncan make target that iterates over wav files in ~/Wav/Seymour Duncan/, converts each one, runs the selected effect, and plays it through ffplay — useful for testing with a larger variety of guitar tones.

# From the Makefile — SeymourDuncan target
for i in ~/Wav/Seymour\ Duncan/*; do
    ffmpeg -y -v fatal -i "$$i" -f s32le -ar 48000 -ac 1 pipe:1 \
        | ./convert phaser \
        | ffplay -f s32le -ar 48000 -ch_layout mono -i pipe:0
done