Forem: SUDIP MONDAL

How I implemented Schroeder Reverb in real-time audio (C++17)

SUDIP MONDAL — Wed, 25 Mar 2026 08:13:38 +0000

What is Schroeder Reverb?

Schroeder Reverb is a classic real-time reverberation algorithm that simulates room acoustics using parallel comb filters followed by series allpass filters. It's computationally efficient while producing convincing reverb effects, making it ideal for real-time audio applications.

The Algorithm

The Schroeder reverberator consists of:

4 parallel comb filters - These create the initial reflections
2 series allpass filters - These add diffusion and smear the sound

Each comb filter uses a feedback topology:

float CombFilter::process(float input) {
    // Read from circular buffer at delay time
    float delayed = buffer[writePos - delayTime] & BUFFER_MASK;
    float output = delayed * (-feedback);

    // Mix input with feedback
    float mixedInput = input + output;

    // Write to buffer
    buffer[writePos] = mixedInput;
    writePos = (writePos + 1) & BUFFER_MASK;

    return delayed;
}

Implementation Details

Comb Filter Delays

Typical delay times (in milliseconds) for 44.1kHz sample rate:

Comb 1: 25.31ms
Comb 2: 26.94ms
Comb 3: 28.63ms
Comb 4: 30.47ms

These are prime number-based delays to avoid comb resonances at audio frequencies.

Allpass Filters

Allpass filters are crucial for diffusion:

float AllpassFilter::process(float input) {
    float delayed = buffer[writePos - delayTime] & BUFFER_MASK;
    float output = delayed + (input * -feedback);

    buffer[writePos] = input + (delayed * feedback);
    writePos = (writePos + 1) & BUFFER_MASK;

    return output;
}

Allpass delays are typically shorter (5-17ms) than comb filters.

Key Implementation Tips

Use circular buffers - Allocate based on max delay time at your sample rate
Feedback coefficient - Keep between 0.5-0.9 to avoid instability
Dry/wet mix - Combine the dry input with the reverb output (typically 30% wet)
Denormal handling - Add small noise floor to prevent denormal CPU stalls

float output = drySignal * (1 - wetMix) + 
               reverbSignal * wetMix;

// Prevent denormals
if (fabs(output) < 1e-6) output = 0;

Performance

Schroeder reverb is extremely efficient:

6 filters total (4 comb + 2 allpass)
~3KB memory for buffers at 44.1kHz
~0.1ms latency with optimized code
Minimal CPU usage - runs easily on embedded systems

Tuning the Sound

Tweak these parameters for different room characteristics:

Damping: Low-pass filter in feedback path (reduces high frequencies)
Feedback amount: Higher values = longer decay
Wet/Dry mix: More wet = more obvious reverb
Delay times: Pre-calculated for room size

The beauty of Schroeder reverb is its simplicity and efficiency. With just a few parameters, you can create convincing spatial effects perfect for guitar sims, synthesizers, or any real-time audio application.

Want to see it in action? Check out Amplitron's full implementation in the main article!

Just launched Amplitron on Product Hunt today — a free, open-source guitar amp simulator I built in C++17. Implements Schroeder reverb, biquad EQ, and tanh waveshaping from scratch. ~1.3ms latency. Linux/Mac/Windows. Check it out!

SUDIP MONDAL — Wed, 25 Mar 2026 08:10:07 +0000

SUDIP MONDAL

Mar 24

I Built a Free, Open-Source Guitar Amp Simulator in C++17 — Here's How

#cpp #opensource #audio #music

Comments 1

3 min read

Ask the community: building real-time audio in C++ — what would you add?

SUDIP MONDAL — Wed, 25 Mar 2026 00:32:30 +0000

I’m actively developing Amplitron, a free open-source guitar amp simulator in C++17, and I'd love to get community input on the direction of the project.

The core is solid — we have DSP effects chains, tube amp modeling, and cabinet simulation working well. But I want to know what would make it more useful for the community.

Some ideas I’m considering:

More effects types (reverb, delay, modulation effects)
MIDI controller support
Multi-amp/split chains
Better visualization of the signal chain
Plugin version (VST/AU)

But I’m curious: what effects or features would YOU prioritize if you were building a guitar amp simulator? Are you a guitarist, game developer, or audio enthusiast? What would make this tool actually useful for your projects?

Feel free to check out the full implementation here: https://dev.to/sudipmondal2002/i-built-a-free-open-source-guitar-amp-simulator-in-c17-heres-how-1d86

Looking forward to hearing your ideas!

I Built a Free, Open-Source Guitar Amp Simulator in C++17 — Here's How

SUDIP MONDAL — Tue, 24 Mar 2026 20:44:24 +0000

I Built a Free, Open-Source Guitar Amp Simulator in C++17

If you've ever wanted to practice guitar silently through headphones or do quick home recordings without spending $20+/month on commercial amp sim software, this project might interest you.

I built Amplitron — a free, open-source guitar amp simulator that runs on Windows, macOS, and Linux. Here's the technical story behind it.

The Problem

Commercial guitar amp simulators (Bias FX, Guitar Rig, AmpliTube) are excellent but expensive. If you just want to:

Practice silently through headphones
Record a quick demo track
Experiment with guitar tones

...paying $20-40/month feels excessive.

So I built Amplitron. It's MIT licensed, completely free, and runs natively without any cloud or subscription.

Tech Stack

C++17 — for the core application and DSP engine
PortAudio — cross-platform audio I/O (WASAPI/ASIO on Windows, CoreAudio on macOS, ALSA/PipeWire/JACK on Linux)
Dear ImGui + SDL2 — for the visual pedalboard interface
CMake — build system with vcpkg support on Windows
GitHub Actions — CI/CD for all 3 platforms (builds + tests on every push)

The Audio Engine

The most important design consideration for real-time audio is latency. The default configuration runs at:

Buffer size: 64 samples
Sample rate: 48kHz
Processing latency: ~1.3ms

At 64 samples, you have roughly 1.3ms before the audio buffer underruns. The audio callback does all DSP work in that window.

Thread Safety

The trickiest part of building a real-time audio app with a GUI is thread safety. The audio callback runs on a high-priority thread, and the GUI thread modifies the effect chain (add/remove effects, change parameters).

My solution: the effect chain uses try_lock on a mutex:

// Audio callback — never blocks even if GUI is modifying effects
void AudioEngine::processBuffer(float* output, const float* input, size_t frames) {
    if (effectChainMutex.try_lock()) {
        for (auto& effect : effectChain) {
            if (effect->isEnabled()) {
                effect->process(output, frames);
            }
        }
        effectChainMutex.unlock();
    }
    // If lock fails, just pass audio through unprocessed this buffer
}

This ensures glitch-free audio even during heavy UI interactions.

The DSP Effects

Here's the technical breakdown of each effect:

Overdrive (Tube-Style Soft Clipping)

Classic tube amp overdrive uses asymmetric soft clipping. My implementation:

float overdrive(float x, float drive) {
    x *= drive;
    // Asymmetric soft clipping — positive half clips harder
    if (x > 0) {
        return x / (1.0f + std::abs(x));  // soft clip positive
    } else {
        return x / (1.0f + 0.5f * std::abs(x));  // softer on negative
    }
}

Distortion (Hard Clipping + Waveshaping)

Uses tanh() for smooth hard clipping with tonal character:

float distortion(float x, float gain) {
    return std::tanh(x * gain) / std::tanh(gain);
}

EQ (Biquad Filters)

The 3-band parametric EQ uses biquad filters:

Bass: Low shelf filter
Mid: Peaking filter
Treble/Presence: High shelf filter

Biquad filters are the standard for audio DSP — they're computationally cheap (5 multiply-adds per sample) and numerically stable.

Reverb (Schroeder Algorithm)

Schroeder reverb simulates room acoustics using:

4 parallel comb filters — create the initial reflections and sustain
2 series allpass filters — add diffusion and "smear" the sound

Input → [Comb 1] ─┐
Input → [Comb 2] ─┤→ Mix → [Allpass 1] → [Allpass 2] → Output
Input → [Comb 3] ─┤
Input → [Comb 4] ─┘

Cabinet Simulation

Speaker cabinet emulation uses a combination of:

Low-pass rolloff (speakers don't reproduce ultra-high frequencies)
High-pass rolloff (speakers have a low-frequency cutoff)
Resonance peak at the speaker's natural frequency

The Visual Pedalboard

The UI is built with Dear ImGui, which is a great fit for real-time audio apps because:

Immediate mode: redraw every frame, perfect for real-time meters
Lightweight: minimal overhead
Custom rendering: easy to make it look like a physical pedal

Each pedal is rendered with:

Color-coded body (different color per effect type)
Rotary knobs (drag vertically to adjust — just like physical knobs)
LED indicator (bypass state)
Footswitch button to toggle bypass

Cross-Platform CI/CD

Every push to main automatically:

Builds on Windows (MSVC + vcpkg), macOS (Homebrew), and Linux (apt)
Runs the full test suite (64+ tests covering all 9 effects)
Creates a release with binaries for all platforms

This was surprisingly easy to set up with GitHub Actions.

What's Next

VST3 plugin version (so it works inside DAWs)
More amp models (currently just the pedal chain approach)
IR-based cabinet simulation (using impulse responses for more realistic cab sound)
MIDI control for footswitch bypass

Try It

GitHub (+ downloads): https://github.com/sudip-mondal-2002/Amplitron
Website: https://amplitron.sudipmondal.co.in
Product Hunt: https://www.producthunt.com/products/amplitron

It's MIT licensed and completely free. Contributions welcome!

What would you add to a guitar amp simulator? I'd love to hear what effects or features matter most to you.