The Audio Engine

The engine is the machinery underneath the console: it captures your sources, runs all the processing, and delivers audio to your devices — continuously, in real time. The UI is just the remote control; the engine does the work.

Start and stop

The ▶ / ⏹ buttons at the right end of the monitor bar control it. The dot next to them shows the state — green for running, grey for stopped. While the engine is stopped, no audio flows and the meters sleep; your settings, of course, stay put.

You'll rarely need ⏹ in daily use. The main reason to restart is applying changed audio settings: when you switch driver mode or buffer size in Settings → Audio, a banner reminds you the change takes effect after a restart (⏹ then ▶).

If the engine hits a problem, a ⚠ icon appears next to the engine controls — hover it to read the error.

The fixed format: 48 kHz / 32-bit float

Internally, the engine always runs at 48,000 samples per second with 32-bit floating-point precision.

• 48 kHz is the native rate of modern Windows audio, games and video — so most sources pass through without conversion. Devices running at other rates are converted automatically; you never need to match rates by hand.
• 32-bit float gives the math enormous headroom: levels can exceed 0 dB inside the engine without distortion. Clipping only becomes real at the final output — which is what bus limiters are for.

Buffer and latency

Audio is processed in small batches called buffers. The buffer size (Settings → Audio) is the engine's basic trade-off:

Buffer	Latency	Character
smaller	lower	you hear yourself sooner, but the CPU must keep a tighter deadline
larger	higher	more relaxed timing, more resistant to glitches

The default — 480 samples = 10 ms — is a sweet spot: low enough for comfortable self-monitoring, robust on ordinary hardware. WASAPI Exclusive mode unlocks smaller buffers (down to 2.7 ms) for low-latency hardware; details live in the Settings → Audio chapter.

Reading the status bar

While running, the status bar reports once a second:

Running | 48000 Hz | Latency: 10.0 ms | CPU: 2.3% | Ovr: 0 | Und: 0

• CPU — the DSP engine's own processing load (not the whole system's). If this climbs toward saturation, audio glitches follow.
• Ovr (overruns) — a source delivered audio faster than it could be consumed; a moment was dropped.
• Und (underruns) — an output needed audio before it was ready; a gap was played.

A few counts after plugging devices or under a momentary system spike are nothing. Steadily climbing numbers while audio crackles are the signature of a too-small buffer or an overloaded system — the Crackling and latency troubleshooting page walks through the fix. The counters reset when the engine restarts.

The engine heals itself

Real life happens to audio setups, and the engine is built to ride through it:

• Unplugged device — the affected channel or bus goes silent and its device dropdown shows ⚠ … — disconnected; everything else keeps playing. Plug it back in and audio resumes automatically.
• Sleep / wake — after Windows resumes from sleep, the engine restarts itself; no action needed.
• Closing a captured app — an APP channel simply waits and resumes when the program is back.

When recovery isn't automatic, a manual ⏹ → ▶ cycle is the universal "have you tried turning it off and on" of the audio world — and it genuinely fixes most transient weirdness.