Combining audio nodes (wet/dry convolver) outputs glitchy audio

[plasticrake]

Description

My first Expo/RN project so please forgive me if missing something simple here.

I'm trying to implement reverb with wet/dry mix like below:

Routing: source →\-→             dryGain → destination
                  \→ convolver → wetGain → destination

By themselves, the dry and wet routes sound fine (if I comment out the other). But if I have them both together the audio sounds very glitchy and the playback runs fast. I ran a similar setup using Web Audio (not using RN) in browser and it worked fine.

I extracted out a simple example to github as requested (can you even run things from a snack that use react-native-audio-api?) I'm using the same reverb code from the pedal example. But I had tried my own reverb version and even a worklet version and they all had similar issues.

Here is the key part of the code:

	sourceRef.current
		.connect(dryGainRef.current)
		.connect(audioContext.destination);

	sourceRef.current
		.connect(convolverNodeRef.current)
		.connect(wetGainRef.current)
		.connect(audioContext.destination);

Am I missing something or is this a bug?

I've tested on iOS/Android simulator and an Android device.

Steps to reproduce

1. Clone repo
2. npm install
3. expo run
4. Open app
5. Audio will auto play and sound horrible!
6. Feel free to use the slider to add reverb to the horrible noises!

Snack or a link to a repository

https://github.com/plasticrake/reverb-dry-wet-test

React Native Audio API version

0.11.7

React Native version

0.83.2

Platforms

iOS, Android

JavaScript runtime

Hermes

Workflow

Expo Go

Architecture

Paper (Old Architecture)

Build type

None

Device

iOS simulator

Device model

No response

Acknowledgements

Yes

[learnwithemu]

We hit this exact issue building a reverb effect in our React Native app (also v0.11.7). Our findings:

▎ - Any branching signal path (source → dry gain + source → convolver → wet gain) produces sped-up, distorted audio. Confirmed with both
ConvolverNode and DelayNode.
▎ - A single linear chain (source → gain → destination, no branching) plays back cleanly — we verified this by bypassing the effect chain
entirely.
▎ - Additionally, we found a crash bug in Convolver::process(): the C++ code in Convolver::init() trims trailing IR samples below 10e-3
(0.01). If ALL samples fall below this threshold, irLen becomes 0 and init() returns early without initializing _fft, _segments, or
_inputBuffer. When process() is subsequently called, it accesses these uninitialized members and crashes with SIGABRT (memory corruption /
null pointer).

▎ Platform: iOS simulator, macOS 26, arm64.

Claude wrote this :) but yeah in my app, also finding it hard to get this working for a simple reverb POC.

[learnwithemu]

details on a workaround -

Workaround for branching signal path distortion (issue #1000)

We hit the same issue building a reverb effect. After extensive debugging, we found a workaround: avoid branching in the Web Audio graph entirely by using a separate audio system for the dry signal.

Architecture:

• Dry signal: played through react-native-sound (completely separate from the Web Audio graph)
• Wet signal: linear chain only — AudioBufferSourceNode → ConvolverNode → GainNode → context.destination
• Mix control: a fader adjusts the wet GainNode (send mode — dry is always at full volume)

Since the dry and wet signals go through entirely independent audio systems, there's no branching in the Web Audio graph at all. The ConvolverNode sits in a simple linear chain and works correctly.

Additional ConvolverNode bugs we found and worked around:

1. Crash if IR samples are all below 0.01: The C++ Convolver::init() trims trailing samples below 10e-3. If ALL samples fall below this threshold, irLen becomes 0 and init() returns early without initializing _fft, _segments, or _inputBuffer. Subsequent calls to process() crash (SIGABRT — null pointer / buffer overflow). Fix: ensure IR tap gains are > 0.01.

2. ConvolverNode self-disables after inputs stop: When all input nodes go silent/disconnected, the C++ code calls disable() and never re-enables, even when new audio arrives. Fix: when swapping audio sources, connect the new AudioBufferSourceNode to the gain node before disconnecting the old one, so the gain node (ConvolverNode's input) never has zero connected sources.

3. normalize=true causes massive amplification: With quiet IRs, the auto-normalization boosts gain dramatically, causing clipping. Fix: set convolver.normalize = false and manage gain manually.

4. Echo artifact on release: With discrete-tap IRs, stopping audio with a slow gain ramp (20ms) feeds a long chunk into the convolver tail, producing audible repeating echoes at each tap position. Fix: use a very fast source mute ramp (2ms) so the convolver tail only contains tiny slivers that blend together naturally.

This workaround gives us clean, controllable reverb on both file and oscillator sources. Not ideal (two audio systems running in parallel), but functional until the branching bug is fixed.

[mdydek]

I know that it is really inconvenient, but for now our api does not support multiple outputs from the same node, however our scheduling is very precise and this code will work perfectly fine

sourceRef.current
	.connect(dryGainRef.current)
	.connect(audioContext.destination);

sourceRef2.current
	.connect(convolverNodeRef.current)
	.connect(wetGainRef.current)
	.connect(audioContext.destination);

sourceRef.current.start(audioContext.currentTime);
sourceRef2.current.start(audioContext.currentTime);

source1 → dryGain → destination
source2 -> convolver → wetGain → destination

there are two exact source nodes that play the same thing, but since they are perfectly aligned, audio is the same as one source node with two outputs. Whole processing refactor is coming.

[mdydek]

@learnwithemu what is the reason behind using impulse response with all values below 0.01? Have you compared behavior with web audio api and can confirm that on web it works fine?

[plasticrake]

@mdydek, that is unfortunate, I have other effect nodes in the chain as well and they would all have to be duplicated. And if I wanted two effects to have wet/dry then I would have 4 parallel chains!

Can you share when support for this may be coming?

[mdydek]

most of the work is done, rest is currently being developed in #991, we will try to do that probably in a few days, but I cannot promise you anything unfortunately

[learnwithemu]

@learnwithemu what is the reason behind using impulse response with all values below 0.01? Have you compared behavior with web audio api and can confirm that on web it works fine?

From Claude :)

IR design rationale:

We generate a WAV in memory with discrete impulse taps (rather than random noise) for two reasons: noise IRs sounded metallic through the ConvolverNode, and discrete taps gave us cleaner early reflections. We encode it as a real WAV and run it through decodeAudioData() because JS-created AudioBuffers caused crashes or silence — the native C++ ConvolverNode expects a buffer from the native decoder path.

The bigger constraint was the trim threshold in Convolver::init(). The C++ code discards any IR samples with absolute value below 0.01. If all samples fall below that (which happens easily with subtle reverb — 0.01 is about -40dB), internal members never get initialized and process() hits a SIGABRT. No JS error, just a hard native crash. Our lowest tap sits at 0.011 — we had to design the entire IR around that floor. Natural reverb tails want to decay well below 0.01, so we can't trail off to silence the way you normally would.

---

From the human - thanks for your response to the thread. Awesome work here. Looking forward to the additional support

[mdydek]

@learnwithemu initially trimming the buffer in convolver node was required because convolver algorithm was very expensive, but currently it does not have this problem, maybe we will discard it

[mdydek]

tail trimming discard is in #1019