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

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.

The issue names WorkletProcessingNode::processNode and createWorkletProcessingNode as entry points, plus a platform-free TypeScript reference implementation with unit tests and parity vectors. Start by locating the native audio graph and those worklet paths; done would be a native DynamicsCompressorNode or a stable C++ extension point validated against the supplied vectors.