Skip to content

Multi reverb engine support#1760

Open
derselbst wants to merge 79 commits into
masterfrom
multi-reverb-support
Open

Multi reverb engine support#1760
derselbst wants to merge 79 commits into
masterfrom
multi-reverb-support

Conversation

@derselbst

@derselbst derselbst commented Feb 22, 2026

Copy link
Copy Markdown
Member

This PR implements my idea posted in #1157: Providing multiple built-in reverb engines. In effort to fix problems #1496 and #1215.

TL;DR: Check out the new reverb overview with audio samples in the API docs.


This PR currently adds 4 additional reverb engines to fluidsynth, which can be selected via the new setting synth.reverb.engine or via the -R flag for convenience:

  • -R fdn - The default FDN reverb
  • -R free - Fluidsynth's pre-2.1.0 reverb "Freeverb"
  • -R lex - LEXverb
  • -R dat - Dattorro Reverb
  • -R smith - Signalsmith Reverb

The existing FDN was used to derive a C++ base class from it, which every engine inherits from, to provide a common interface for rvoice_mixer.

Users who are interested in testing the reverbs themself - with optional parameter tweaking - can do so by building the renderReverbOverview CMake target, which will render audio to build/test/manual/reverb/.

Implementation details of the reverbators can be obtained from the liked papers from the API docs, or from the source code / header file, which may or may not include a block chart in ASCII art.

Breaking Changes

  • In version 2.4.0 the default synth.reverb.damp setting was changed to 0.3. After having played around a lot with reverb in the last weeks, I conclude that this was a mistake. At least for the default FDN reverb, damp=0.3 always sounds too much like a garage or metal bucket to me. This PR changes the default damp value back to 0.

TODO

  • I don't like the way the damping parameter affects LEXverb: it doesn't really "damp" it rather "undoes" the effect of synth.reverb.level - is there a better approach to this?
  • The logic in the synth involving with_reverb, fluid_synth_reverb_on() etc should be revised / simplified
  • Clarify, how the different reverb engines should be selected: with an int or string setting? (int setting would be backward compatible, but numbers may change for future versions; string setting would be a breaking change, but more future safe, or a completely new string setting...)
  • General reverb settings rehearsal / tuning for LEXverb
  • General reverb settings rehearsal / tuning for Dattorro
  • Clarify, which of those reverb engines to keep in fluidsynth
  • Clarify, which of those reverb engines to become default
  • Out of scope for this PR but to be kept in mind: Revive Support stereo fx send to LADSPA #1170 - Ability for stereo fx

I should add that ChatGPT-5.2 was a huge help and time safer to get all those different implementations plugged together and integrated into fluidsynth's 4-reverb-settings universe. Something that was unthinkable when I initially brought up this topic on our mailing list almost four years ago.

Resolves #1157, #1496, #1215

Copilot AI and others added 30 commits February 22, 2026 16:37
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
@derselbst derselbst marked this pull request as ready for review April 19, 2026 12:32
@sonarqubecloud

Copy link
Copy Markdown

@derselbst

Copy link
Copy Markdown
Member Author

I announced that topic on our mailing list and on Github discussion. Feel like an eternity. No feedback so far, just 3 upvotes. If it stays that way I will merge it as is, i.e. keep all four engines for now and keep FDN as default engine (to remain compatible in how the reverb parameters behave / influence the reverb sound). I'll reserve the option to remove freeverb in a future release again, as it sounds worst compared to the others.

@es20490446e

Copy link
Copy Markdown
Contributor

Damping slightly worsens audio quality, but makes it more natural.

I chose to use damp 0.3 because when the music was played along with other effects in games, the music sounded way too synthetic and disconnected from the effects.

When you damp the sound it appears to come from a real room. This is what Christian Collins also did.

Also note that if you aren't listening to the music using calibrated studio speakers (not headphones) the "can effect" of your own equipment may be exaggerated by the artificial damping of the synth.

This will be more pronounced if your equipment doesn't have proper bass definition. Non studio speakers usually have boosted bass, with lack of representation on the lowest frequencies, and even plastic-like resonance.

The speakers I used to set the defaults have a studio subwoofer, calibrated using a calibration microphone.

@derselbst

derselbst commented May 30, 2026

Copy link
Copy Markdown
Member Author

It's all good :) It's just for the few songs I've tested I perceived that damping sounded unpleasant for all 4 reverb engines. During development I wanted to hear the clean "reverb tail" which damping ruined. Oh, and I'm using headphones - no studio equipment.

Just continue testing, I'm keen about what you come up with. I'm sure we'll come to an agreement.

PS: This PR is currently blocking fluidsynth 2.6.0 - I was planning the release to happen around July / August. Pls. let me know in case you need more time.

@es20490446e

Copy link
Copy Markdown
Contributor

That was my first reaction when Christian Collins suggested me to use that level of damping.

But when I played a game like Heretic on DosBox staging using damping, it actually sounded better despite the loss of clarity.

An alternative would be to use damping, but to a lower level.

Headphones have two limitations. Even with reference headphones the bass definition isn't really the same at the lowest frequencies.

And it being binaural you can't really tell how well the stereo channels merge together. It may sound perfectly okay when on headphones, but unpleasant to listen on the speakers. For example, this happens a lot when you use a stereo-widening effect.

Last time it took me a few months to really figure out how to calibrate the speakers, and what to pay attention when making the settings.

The main issue with audio calibration is that it is barely objective. Any small variance on the equipment or a setting may change certain audio property a lot, while affecting another at the same time.

It is more like an art, like choosing the ideal varnish for an instrument.

Also it is not the same tuning for a particular song, in a particular context, which is relatively easy, than doing so as an universal setting. What will sound ideal with certain song, may sound bad with another. Hence you need plenty of trial and error.

I found that calibrating image is relatively easy compared with audio. It's just more objective, and subject to less variance.

Just my thoughts 😅

@es20490446e

Copy link
Copy Markdown
Contributor

Forgot to mention: I will test this almost immediately. I don't think it will took as much time as the last time, as now I know what to pay attention to.

@sonarqubecloud

sonarqubecloud Bot commented Jun 4, 2026

Copy link
Copy Markdown

@derselbst

Copy link
Copy Markdown
Member Author

I've realized that Signalsmith Audio Basics - the library which fluidsynth 2.6 will be using for its limiter - also ships a reverb engine. I've now added it to this PR as well. It's an FDN based reverbator, similar to fluidsynth's current default one, but much better, IMO. Signalsmith is however not a candidate to become fluidsynth's new default engine, because it's way too CPU hungry and may not be suited for real-time scenarios.

Now that we have such a nice wiki, I've also updated the docs once again to not only mention the signalsmith reverb engine, but also attempted to compare all 5 engines regarding their design and tried to assess their quality.

Yet I believe this step paves the way for removing freeverb and FDN in a future version of fluidsynth, since those engines are - IMO - clearly inferior. Looking forward to Alberto's rehearsal.

@spessasus

Copy link
Copy Markdown
Contributor

One thing I'm thinking about: Would it be possible to change fluidsynth's reverb parameters to match one of the GM standards? For example roland GS has the following:

  • Character (essentially the reverb engine)
  • Time (roomsize and width?)
  • Level (same as fluidsynth)
  • Pre-delay time (fluidsynth currently doesn't have that)
  • Pre-lowpass filter (damp?)

If fluidsynth's reverb parameters would be updated to match those, it'd be possible to control them in real-time through standardized GS system exclusives. Which would be quite nice, I think.

This could also potentially apply to chorus as well, but this PR is about the reverb.

@derselbst

Copy link
Copy Markdown
Member Author

No.

standardized GS system exclusives

There is no such thing as "standardized GS system exclusives". GS is not a standard. It's Roland's proprietary implementation (possibly also extension) of General MIDI. System Exclusive messages are never a standard either. As the name suggests those are exclusive to whatever system is in charge to synthesize the audio. I'm not willing to (breakingly) change fluidsynth just to match some proprietary implementation. Making it compatible with it is a different story.

I haven't checked the MIDI standard yet. If there are any recommendations in it that make suggestions about reverb and chorus parameters, we can talk about supporting them... after we have decided on a new default reverb engine and merged this PR. It would surely not happen for 2.6.0. Also timing-wise, there are several other issues around here that deserve my attention before I would consider this change.

@spessasus

Copy link
Copy Markdown
Contributor

No.

standardized GS system exclusives

There is no such thing as "standardized GS system exclusives". GS is not a standard. It's Roland's proprietary implementation (possibly also extension) of General MIDI. System Exclusive messages are never a standard either. As the name suggests those are exclusive to whatever system is in charge to synthesize the audio. I'm not willing to (breakingly) change fluidsynth just to match some proprietary implementation. Making it compatible with it is a different story.

I haven't checked the MIDI standard yet. If there are any recommendations in it that make suggestions about reverb and chorus parameters, we can talk about supporting them... after we have decided on a new default reverb engine and merged this PR. It would surely not happen for 2.6.0. Also timing-wise, there are several other issues around here that deserve my attention before I would consider this change.

Sure, GM2 has standardized reverb time and character, and has fully standardized chorus.

See section 4.4 and section 4.5.
That IS standardized, approved by MMA themselves, as you requested. General MIDI Universal System Exclusives ARE the standard.
I recommended GS because it has more parameters to work with, but sure. GM2 is fine too.

@es20490446e

Copy link
Copy Markdown
Contributor

I will start testing reverb tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reverb Engine Causes Distortion Cyclic modulation of amplitude in the reverb sound Support different reverb engines

5 participants