Feature request: DynamicsCompressorNode and/or a supported custom native node extension point

[kylel1213]

Feature request

DynamicsCompressorNode is currently ❌ in the Web Audio API coverage table, and there is no supported extension point for custom native DSP nodes. We'd love either (ideally both):

1. A native DynamicsCompressorNode (per the Web Audio spec), and/or
2. A supported native extension point for custom audio nodes (a stable C++ interface an external pod/gradle module can implement and insert into the graph).

Why WorkletProcessingNode doesn't cover this

We ship a sleep-audio app (long-form playback, screen locked) with a compressor/multiband/limiter chain implemented as a well-tested TypeScript kernel. We first ran it through createWorkletProcessingNode, and found it isn't realtime-viable for non-trivial DSP in release builds:

• WorkletProcessingNode::processNode runs the worklet synchronously on the audio render thread via executeOnRuntimeSync for every 128-frame quantum (~2.7 ms @ 48 kHz), and allocates JS array views per call.
• Under Hermes (interpreted in release, no JIT) plus runtime-lock/GC contention, a real multiband kernel misses render deadlines; the resulting periodic buffer glitches are audible as harsh distortion — worse with each additional worklet node. A trivial pass-through worklet is fine; real DSP is not.

So today the practical ceiling for WorkletProcessingNode is light-duty processing, and there's no native path for anything heavier.

What we can contribute

We have a platform-free TS reference implementation (single + multiband compressor with LR4 crossovers, brickwall envelope limiter) with sample-exact unit tests and deterministic parity vectors. If a native DynamicsCompressorNode or a custom-node interface lands, we're happy to help validate against those vectors, and could potentially contribute an implementation if maintainers are open to it.

Thanks for the library — the FFmpeg file source and the native graph have been excellent for us.

[mdydek]

have you tried? https://docs.swmansion.com/react-native-audio-api/docs/guides/create-your-own-effect, it allows you to run your custom code directly in c++, which should be muuuuch faster than processing in js

[kylel1213]

Real-world data reinforcing this request — we measured whether a JS-thread control loop could substitute for a native dynamics node (control-rate sidechain: native biquads/gains, JS computing gain at a 30 ms tick).

Overnight instrumented run on a physical iPhone (iOS 26.3.1, release build, screen locked, audio session active): 552 min, 964,128 ticks — 12 gaps >100 ms, 6 gaps >1 s, worst gap 55.9 s, and a 34.4 ms mean interval against the 30 ms target (systematic coalescing on top of hard suspensions).

So JS-driven parameter automation is not viable for dynamics in the backgrounded/locked state that long-form audio apps live in — and per the earlier notes, WorkletProcessingNode can't carry real DSP on the render thread either. A native DynamicsCompressorNode (or a custom-node extension point) looks like the only realtime-safe path for this class of app. Happy to contribute — we have a tested reference implementation and deterministic parity vectors ready.

[mdydek]

I sent you the link to the docs page where there is a step by step guide how to implement your own effect (AudioNode) and onboard it into your application. Processing bypasses JS-thread completely. Maybe I am missing something, will it not suite your needs? From what I am understanding, it would be perfect for your need.