Measurement-Driven Tuning for Car Audio and Multi-Way Loudspeaker Systems
Automatic time alignment with honest verdicts, a virtual DSP crossover designer, engineering-grade acoustic analysis — impulse response, frequency response, phase, loopback-referenced timing, and live transfer functions — and a clipboard bridge that lets any chat assistant read the whole system, measure what a change would do, and propose one you review before it is applied. On Windows.
Measure each driver once, then leave the car: align, combine, and optimize the whole system from your desk — and only then type the result into the DSP.
Download latest release · Tuning manual · Reference · Your first measurement · Build from source
Resonalyze is an open-source desktop application for measuring and tuning multi-way loudspeaker systems — with a special focus on the hardest room of all: the car cabin. It generates test signals, records the response through a Windows audio device, and turns the captured data into engineering-focused plots and concrete DSP settings: crossover corners, per-driver delays, polarity, and PEQ. The same toolset measures rooms, home loudspeakers, headphones, microphones, and complete signal paths.
Its center of gravity is the step most measurement workflows leave to you: turning a set of per-driver measurements into one coherent system. Auto delay and Auto crossover search the actual settings against the phase-aware predicted sum, and every automatic result comes with an honest verdict — the engine reports why it trusts an arrival, and refuses loudly instead of fabricating a number when the measurement cannot support one.
And it can hand that whole diagnosis to a chat assistant. Copy the system to the clipboard, paste it into whichever assistant you already use, and its reply comes back as typed rows in a review — each one against the value your channel holds now, yours to untick or cancel, and nothing written until you press Apply. Or it comes back as a probe, which measures what a crossover, a PEQ bank, a gain or a delay would do and changes nothing while it answers. No account, no API key, no network request: the clipboard is the whole transport.
Resonalyze is under active development. Treat its results as diagnostic measurements, not as certified laboratory data.
Virtual DSP — combine measured drivers through gain, delay, polarity, crossover filters, and PEQ (bells, shelves and all-pass alike) before touching the hardware DSP.
Does the automation actually help? Sum loss — how many dB the real phase-aware sum falls short of a phase-blind magnitude addition at each junction (average / worst dip). Left: a three-way system tuned by ear over years. Right: the same system after one Auto crossover + Auto delay pass — the worst dip shrinks from −8.0 to −2.3 dB.
A chat assistant that can measure. The reply to a pasted package arrives as typed rows, each against the value the channel holds now and none of them written until you press Apply. Here it asks nothing to be changed at all: three probes — twelve crossover candidates on the right C–D junction, the same twelve on the already-good left one, and every channel's excess group delay — each measured on a copy of the chain and handed back through the clipboard, with the tune untouched and nothing to undo.
EQ Wizard equalizes any measured response — an impulse response, a captured overlay curve, or a spatial average from a moving microphone or a microphone array — toward its own target curve. |
Time Alignment estimates loopback-referenced delay from the transfer impulse response, with confidence, levels, distance, and the arrival envelope. |
If you already use REW, OpenSoundMeter, or Smaart: those are broad measurement toolboxes; Resonalyze is a focused, end-to-end tuning workflow for active multi-way systems. REW's alignment tool sums a pair of measurements and its EQ module corrects a response; Resonalyze operates one level up — separate per-driver measurements on one absolute time base, complete virtual DSP chains, a phase-aware sum of the whole system, and optimizers that work every crossover junction and both stereo sides at once. Its home turf is the car, and its output is not just a plot but the DSP settings themselves:
- Built for multi-way active systems — measure each driver separately, then design the whole system virtually: crossover corners, slopes and families, per-driver delay and polarity, and PEQ down to all-pass bands, tuned against the phase-aware predicted sum. Auto crossover and Auto delay search these settings automatically, across both stereo sides in one run.
- A chat assistant that can measure — copy the whole diagnosis to the clipboard, paste it into any chat, and its reply comes back as a table of typed operations judged against your current values, never as settings written behind your back: you untick what you do not want and press Apply. It can also ask instead of guess: a probe measures what a junction would do under a crossover, a PEQ bank, a gain or a delay it names — computed on a copy, with nothing in your tune touched — and hands you the answer to paste back. No account, no API key, no network request: the clipboard is the whole transport.
- Honest automation — an automatic tuner that guesses is worse than none. Arrival estimates carry confidence and verdicts, modal build-up latches and playback crosstalk are detected instead of aligned to, and when a measurement cannot support a decision the engine says so.
- Loopback-referenced timing — a recorded loopback channel is the time reference, so delay and transfer-function analysis are tied to the actual playback path, and separate measurements share one absolute time base.
- Repeatable, calibrated measurements — average up to 64 sweeps into one cross-spectrum transfer estimate with a per-frequency coherence (γ²) curve, and put the response in real dB SPL from an acoustic 1 kHz calibrator.
- Crossover summation prediction — the true complex (vector) sum of two measurements accounts for relative delay, polarity and phase the way dB-curve arithmetic cannot, with a companion sum-loss curve; Virtual DSP takes this to its conclusion with complete virtual chains per driver.
- Fast compare-and-adjust work — persistent and calculated overlays, target curves, on-plot labels, and a measurement history that keeps each entry's whole working state.
Resonalyze does not try to be every acoustic tool at once. For room EQ at home, REW remains excellent; when the question is "what delays, crossovers, and polarities do I put into this six-channel DSP", that is what Resonalyze is for.
A one-minute tour of the main features:
Download the latest ready-to-run build from GitHub Releases:
Resonalyze-Setup-vX.Y.Z-win-x64.exe— the recommended installed buildResonalyze-vX.Y.Z-win-x64.zip— for most Windows computersResonalyze-vX.Y.Z-win-arm64.zip— for Windows on ARM
The .zip builds are self-contained and do not require a separate .NET
installation; the installer adds shortcuts, uninstall support, and automatic
in-app updates for the installed x64 build, and a SHA-256 checksum file is
provided with every release. "Self-contained" refers to the runtime, not to your
data: by default every build keeps settings, history, overlays, Virtual DSP state
and logs in %LocalAppData%\Resonalyze. To make a .zip build fully portable,
create an empty file named portable.flag next to Resonalyze.exe. When a newer
release is detected, the version label in the title bar changes to Update
available and breathes slowly between grey and blue so it is noticed on a bar
nobody looks at: installed builds can start an Automatic Update, portable
builds offer a manual download. The pulse pauses while the window is in the
background, stops once you follow the link, and never starts at all when Windows
is set to show no animations (Settings → Accessibility → Visual effects).
Windows SmartScreen note: the builds are not code-signed (certificates are expensive for a free open-source project), so the first launch may show a "Windows protected your PC" dialog. Click More info → Run anyway, or verify the download against the published SHA-256 checksum.
- Band-defined exponential sweep — the low and high frequency it must cover (20 Hz – 20 kHz) plus a per-octave pace, with the transfer estimate gated to the excited band, and impulse-response JSON save/load
- Mandatory loopback for sweep/IR analysis — every IR-based view is derived from the transfer function (harmonics and THD+N stay on the sweep deconvolution); Live Spectrum can additionally run as a reference-free RTA
- Multi-sweep averaging (1–64 runs) as a cross-spectrum estimate with a per-frequency coherence (γ²) curve, the runs playing back to back
- Analysis views — frequency response, phase, group delay, waterfall, Burst Decay, autocorrelation, harmonic distortion, THD and THD+N, with reliability-anchored phase unwrapping, Fixed/FDW phase windowing, and minimum/excess-phase decomposition
- Calibration — the microphone's 0° profile from
.txt/.cal/.frd/.csvfiles, any number of further named profiles, curves estimated for an off-axis angle from the microphone's geometry (with the uncertainty of that estimate shown), and absolute dB SPL from an acoustic 1 kHz calibrator - Time Alignment — sub-sample delay from the transfer IR, refined by a GCC-PHAT cross-correlation
- Crossover summation prediction — in Frequency Response, the true complex
(vector) sum of two measurements (
Main ⊕ Compare) with Compare delay/polarity controls, plus a sum-loss curve - Virtual DSP — up to twelve L/R driver pairs (plus mono channels) through virtual chains: gain, delay, polarity, Butterworth / Linkwitz-Riley / Bessel / Chebyshev crossovers and PEQ (all-pass bands included), with the complex sum, sum loss, phase tracking, junction read-outs, Δ L−R timing, Auto crossover, a stereo-aware Auto delay, a headphone audition, sessions, tuning-sheet export
- AI assistant bridge — the whole diagnosis to any chat assistant and back through the clipboard: its reply arrives as typed operations reviewed against the current values, each row yours to untick before Apply and refused outright where the tune has moved on, it may ask for Auto delay, Auto crossover or a junction tune rather than invent numbers, and its "what would this do" is answered by probes that measure a variant — another crossover, a bank cleared, a different gain, delay or polarity — without changing anything in the tune
- Live Spectrum — a real-time loopback transfer function with coherence, or a reference-free RTA in relative dB or dB SPL, with selectable excitation (leakage-free periodic pink, pink, brown/red, white, or Silent for the ambient room) and compensation of the noise's own spectral slope; plus a dedicated MMM mode that pins the recipe a moving-microphone average is valid under and saves the capture — raw bins and full recipe — as its own file
- Microphone array — further microphones on spare inputs of the same interface, each with its own calibration, averaged over the listening volume in the same sweep that produces the impulse response; the measurement stores every position's curve and the spread between them, and Virtual DSP and the EQ Wizard read the average in place of the one point the response was measured at
- Compare a second measurement (file or History) across Time Alignment, Phase, Group Delay, Frequency Response and Impulse Response, and overlays — captured, calculated and target curves with styling, curve math, import/export, saved per-mode state, and a live editing preview
- EQ Wizard — up to 32 PEQ bands toward its own target (a parametric shape, or a house curve of your own imported from a text file), from an IR, an overlay slot, a text curve or a Virtual DSP channel handed over for editing (and returned with one click), with Auto Tune, cross-tool import/export and a printable tuning-sheet PDF
- Signal Generator, Measurement History with per-entry working state, a compact Mic/Loop level meter, and four audio backends (MME Compatibility, ASIO, WASAPI Shared and Exclusive) with backend-specific channel routing
Virtual DSP, the EQ Wizard, and Time Alignment are shown in the showcase above; the analysis views:
Frequency Response — smoothing, calibration, an optional dB SPL scale, distortion curves, overlays, targets, and coherence. |
Live Spectrum — a loopback transfer function with coherence and peak hold, or a reference-free RTA in dB SPL, on selectable excitation noise. |
Impulse Response — impulse, envelope (ETC) and step on one timeline, save it as readable JSON, and reuse it across analysis modes without re-measuring. |
Group Delay — timing from the transfer IR, with a millisecond gate, gate offset, and a live impulse-window preview. |
More plots — waterfall, phase, Burst Decay, overlays
To run a release build: Windows 10 or later, working playback and recording devices, a suitable loopback and microphone connection, and optionally an ASIO driver. The self-contained release archives include the .NET runtime.
To build from source: Windows 10 or later, the
.NET 10 SDK — global.json
pins the exact version (rollForward: latestPatch), so an older feature band
fails restore even though it is also .NET 10 — and Visual Studio 2026 with the
.NET desktop development workload, or the .NET CLI.
Use conservative playback levels when connecting physical equipment: start with the output turned down and verify the signal path before measuring.
If you are starting from zero, this is the minimal hardware path — roughly €100–200 total:
- A USB audio interface that can capture two channels at once (any entry-level two-channel interface with phantom power works). The second channel matters because every measurement records a loopback reference alongside the microphone — that is what makes the timing analysis absolute. Many interfaces provide that loopback internally, as extra input channels the driver exposes; on one that does not, a spare physical input serves instead. Community-verified so far: Focusrite Scarlett Solo 4th Gen (the developer's own rig), whose loopback is internal.
- An analog measurement microphone (an inexpensive electret measurement mic with an individual calibration file is ideal). A USB measurement mic such as the UMIK-1 will not work — see the FAQ for why.
- One cable, to feed the system under test from an interface output — plus a second short one only if your interface has no internal loopback, run from another output straight back into a spare input.
Then, in about ten minutes, take one measurement and convince yourself the rig works:
- Wire it up: microphone → the mic input, and one output → the system's input (in a car: the DSP's aux/optical input, with only the driver under test unmuted). The loopback is a channel selection rather than a cable where the interface provides it internally; otherwise run a second output back into a spare input.
- Start Resonalyze, open the measurement settings, select the interface, and
assign the input and loopback channels. The measurement will not start
without a loopback — that is by design. Set Measurements to at least
4: the averaged sweeps lift the response out of the cabin's noise floor and produce the coherence curve that tells you which bands to trust. - Turn the playback level well down, place the mic where your head is, and run the sweeps while watching the input level meter. Then look at Frequency Response, Impulse and Time Alignment, and press Save — saved impulse responses are the raw material for everything else.
Two things are worth knowing from the start. Averaging is not only noise reduction: the runs are combined into one transfer IR and a coherence (γ²) curve, debiased by the number of runs — the raw estimate over K averages reads 1/K even for pure noise, so the stored figure maps that null expectation to 0 and stays comparable across run counts. And this path is impulse-response analysis; for continuous, real-time work without capturing an IR — including the moving-microphone captures used for EQ — use Live Spectrum.
From there, capture and compare with overlays, pin a second measurement with Compare, and revisit older captures in History.
None of this is car-specific: the same two-inputs-plus-loopback rig measures rooms, home loudspeakers, headphones, and complete electrical signal paths. For acoustic work the microphone position and the room dominate the result; for an electrical loopback measurement, check that the levels and impedances are safe for both devices first.
If a device will not open, or the sample rate is refused, the backend is usually the reason — see Audio Backends.
This page is the introduction. The rest is split in two, by the question you are asking:
- MANUAL.md — Professional Car Audio Tuning with Resonalyze. The workflow, in order: measuring every driver, building the virtual car, designing the crossovers, equalizing each channel, aligning time and phase, exporting the tuning sheet, and verifying it back in the car. Start here if you have a car to tune.
- REFERENCE.md — every mode, panel and setting. What each control does and why it behaves as it does. Start here if you want to know what a particular graph, read-out or option means.
Two more are written for the chat assistant rather than for you, and are worth a look if you use the bridge: docs/agent/AGENT_GUIDE.md, the tuning methodology an assistant is asked to follow, and docs/agent/PROTOCOL.md, the exact shape of what leaves and enters the clipboard.
Can I use a UMIK-1 or another USB microphone?
No — and it is physics, not stubbornness. Every measurement records a loopback reference next to the microphone signal, and the two streams must share one hardware clock to stay sample-accurate. A USB microphone is its own audio device with its own free-running clock; pairing it with a separate playback/loopback device gives two streams with an unknown run-to-run start offset plus continuous drift, which silently corrupts every timing-sensitive result. This is also why the settings do not offer a separate loopback device.
Why is the loopback mandatory? REW works without one.
The loopback records what actually left the playback chain and exactly when, so every analysis is derived from the mic-vs-loopback transfer function — timing becomes absolute rather than relative to an arbitrary trigger. That absolute time base is what allows separate measurements, taken minutes apart, to be combined later: it is the foundation of the measure-once-tune-at-your-desk workflow, of the complex (vector) sum prediction, and of automatic delay alignment.
Is one microphone position enough to tune a whole car?
At that one point, yes, and exactly: sound pressure sums linearly, so the predicted combination of individually measured drivers is the physics of what the microphone would record — not an approximation. The honest boundaries are the ones any single-point method has: the prediction holds at the microphone position (put it where your head is), in the linear non-clipping regime, with the same playback chain and mic position for every measurement, and at a roughly stable cabin temperature. For frequency-response work you can go further with spatial averaging. And the final judge of a tune is still your ears.
Does the AI bridge send my measurements anywhere?
Only where you paste them. Resonalyze holds no account, no API key and no model: it writes a package to the clipboard, you decide which chat sees it, and its reply comes back the same way. The bridge itself makes no network request. The package carries curves, settings and whatever you typed into the session's notes — never file paths, folder names, your Windows user name, or raw impulse responses — and nothing an assistant proposes reaches the tune until you press Apply in the review, where every row is judged against your current values and any of them can be unticked; a probe changes nothing at all. Use none of it and the program is exactly what it was.
git clone https://github.com/DIMOSUS/Resonalyze.gitThen open source/Resonalyze.sln, or build and run from the command line:
dotnet restore source/Resonalyze.sln
dotnet build source/Resonalyze.sln --configuration Release
dotnet run --project source/Resonalyze.csprojRun all application and deterministic DSP tests with:
dotnet test source/Resonalyze.sln -c Release --filter "Category!=Hardware"That covers Resonalyze.Dsp.Tests (deterministic and synthetic),
Resonalyze.App.Tests (file formats and non-UI application logic against a fake
audio factory) and Resonalyze.Audio.Tests (PCM decoding, capture sessions,
WASAPI configuration). The filter drops the hardware smoke tests, which need real
WASAPI endpoints named through the RESONALYZE_WASAPI_CAPTURE_ENDPOINT_ID and
RESONALYZE_WASAPI_RENDER_ENDPOINT_ID environment variables.
For local performance profiling, build the dedicated Tracy configuration
(dotnet run --project source/Resonalyze.csproj -c Tracy), which defines
TRACY_ENABLE and references Tracy-CSharp. Add instrumentation through
AppProfiler.Zone(...), AppProfiler.FrameMark(...) and
AppProfiler.SetThreadName(...); zones are thread-bound and strictly LIFO, so
never let one span an await.
The Release executable is produced at
source/bin/Release/net10.0-windows/Resonalyze.exe; tagged releases also produce
portable .zip packages for win-x64 and win-arm64, an x64 Setup.exe
installer, and NetSparkle appcast files. The build.yml workflow runs on every
push to main and every pull request: it builds the solution, runs all three
test projects, then proves the release path still works by producing the
single-file publish and compiling installer/Resonalyze.iss. Warnings are
errors.
Resonalyze/
|-- source/ WinForms application: composition root, measurement
| | lifecycle, and plot presentation
| |-- History/ Measurement history snapshots and persistence
| |-- LiveSpectrum/ Live analyzer orchestration
| |-- Measurements/ Sweep/noise orchestration, signal generation, IR files
| |-- ModeSwitching/ The analysis-mode catalogue and tab controller
| |-- Options/ Measurement and visualization settings panels
| |-- Overlays/ Persistent overlay slots and calculated overlays
| |-- Plotting/ OxyPlot model creation, annotations, and adapters
| |-- Settings/ Settings file, schema migrations, update checking
| |-- Shell/ Main form, title bar, commands, and docked settings
| |-- TimeAlignment/ Loopback delay measurement UI and orchestration
| |-- Tools/ EQ Wizard, Signal Generator, Virtual DSP, PEQ import/export
| `-- Ui/ Reusable WinForms controls and dialogs
|-- dsp/ Reusable signal-processing library (no UI, no audio)
|-- audio/ Audio drivers and device access (NAudio lives here)
|-- tests/ App, audio, and synthetic DSP test projects
|-- installer/ Inno Setup script for the Windows installer
|-- assets/ Images used by the README and the application
|-- .github/workflows/ CI builds and automated tagged releases
|-- global.json Pinned .NET SDK version
`-- README.md
The three projects have deliberate boundaries. Resonalyze.Audio owns every
audio driver — MME, ASIO and both WASAPI modes — along with device enumeration,
format negotiation and capture lifecycle; NAudio is confined to it and is not
even referenceable from the application at compile time. Resonalyze.Dsp is pure
signal processing with no UI and no audio dependency: FFT analysis, windowing,
calibration, smoothing, impulse processing, phase analysis, group delay,
crossover and EQ design. The application project wires the two together.
- .NET 10, Windows Forms, OxyPlot
- NAudio and NAudio.Asio
- Math.NET Numerics
- NetSparkle — in-app updates
- YamlDotNet — CamillaDSP profiles
- PDFsharp / MigraDoc — tuning-sheet PDFs
Third-party package licenses are listed in THIRD-PARTY-NOTICES.md.
Bug reports, reproducible measurement cases, DSP corrections, and focused pull
requests are welcome. Known technical debt and improvement ideas are collected in
TODO.md — a good place to look for a first contribution. When
reporting a measurement issue, include the audio interface and driver, the sample
rate and bit depth, the measurement mode, the relevant analysis settings, the
expected and actual behavior, and a screenshot or exception stack trace —
unexpected errors are appended to crash.log in the application data directory.
Resonalyze is available under the MIT License.