Keeping audio consistent everywhere

Parity is about making the same sound behave consistently wherever it runs.

A sound should keep its character as it moves from the browser to a native app, plugin host, or hardware device. We do not rely on listening to a preset on one setup and calling it close enough. We test the same scenarios across many environments and use automated checks to catch problems before they reach users.

Begin with repeatable scenarios

We test with known inputs, timing, settings, and reset states, then run those scenarios across runtimes and build targets. We vary the conditions that commonly expose differences, including buffer sizes, channel layouts, retriggers, and overlapping voices.

That gives us a fair comparison. If something changes, we can tell whether the audio engine changed or the surrounding environment did.

Check every part of the journey

We test the same behavior in browsers, native builds, and supported plugin paths. Where possible, we render results offline so they can be compared and reproduced. We also test the boundaries around real hardware, where drivers, CPU features, buffer sizes, sample rates, and scheduling can affect what the engine receives.

This helps us separate differences caused by the device from differences caused by the audio engine.

Make sure every control earns its place

Automated sweeps check that controls actually do something, work across their full range, and remain safe while audio is playing. They help us find controls that have no effect, unstable settings, unexpected silence, clipping, or behavior that changes when a value is adjusted.

We also check the rendered audio for basic health: valid samples, safe levels, clean transitions, stable tails, and the expected output on each channel. Matching outputs are not enough if both are wrong, so these checks are kept separate from parity checks.

Batch checks for effect developers

maru module eval renders a Graph module offline and reports the same audio-health measurements, maru module eval --suite levels renders a module's actual Processor at several input levels and compares output with input loudness, and maru module verify compares compiled programs with the module's reference output; see Check output levels and Check, build and export. Maru's quality checks are also available as functions for your own tests: render the module's actual Processor, then use analyzeAudio for peak, RMS, DC, clipping, non-finite samples, and discontinuities; checkAudioQuality or assertAudioQuality applies the product's limits. assertParameterEffect checks that parameter variants produce a meaningful output change. compareAudio compares rendered buffers across backends. Automation probes use discrete calls to the module's real parameter setter, so they can expose clicks, zipper noise, and per-event resets caused by knob edits.

Maru's own Multifx is checked this way. Its batch check renders every selectable effect with a repeatable input and tail, compares authored DSP against fresh compiled WASM, and checks finite samples, nonzero output, peak limits, bypass, and dry/wet behavior. Additional fixtures cover macro responses, factory chains, reset/state behavior, and live edits. A complementary face-to-host check in the development workbench selects the 21 newer profiles through the actual face, verifies their starting settings and slot enablement, checks that the selection remains stable, and measures paired input/output captures. It tests the M/S decoder after an encoder, where stereo recovery is the expected result. It does not qualify a native plugin or replace the offline batch gate.

Choose quality limits for the algorithm. Crackle/dust intentionally generate impulses on silence; distortion intentionally changes harmonics; a de-esser needs input above its detector threshold. M/S encoder/decoder identity is a valid roundtrip, rather than evidence of an inert effect. Measure these expected behaviors alongside level, DC, finite-output, and transition checks.

A batch pass establishes those measured properties for the tested fixtures. Also audition representative music at matched loudness, check extreme controls and mono compatibility, and test the built plugin in its intended host. Measurement and listening answer different parts of whether an effect sounds right. See Testing your VST for the host checks and the DSP reference for algorithm-specific operating limits.

Turn surprises into coverage

When two paths should behave the same, we compare their results. When a platform boundary is expected to behave differently, we check it against the right quality criteria. Each result keeps its execution context, making it easier to trace a difference back to a repeatable scenario.

When we find a real regression, we add a test for it. Over time, that gives us broader coverage and makes parity part of the development process rather than a final check.

Our goal is straightforward: audio should remain dependable and portable, whatever environment it runs in.