Why KahuStack DSP Is Building Audio Analysis Primitives

A meter is usually treated as an application: feed it audio, draw some bars, and report a number.

For KahuStack DSP, we want to work one level deeper.

Our analysis of Airwindows Meter exposed an especially useful idea: interesting information about audio can be found not only in loudness or frequency balance, but in the pattern and distribution of waveform events over time.

Meter reaches that idea with a few surprisingly simple observations. It watches sample peaks, waveform slew, zero-crossing intervals, and sustained near-ceiling activity. It then tracks how those observations move through different ranges over time.

We do not want to clone that plugin. We want to extract the reusable ideas underneath it.

That means creating a new family of Rust audio-analysis primitives.

Small measurements, reusable everywhere

The first layer contains extremely small measurements:

• Sample peak — the largest absolute sample magnitude.
• Sample delta — how much one sample changes from the previous sample.
• Slew rate — sample-rate-normalized waveform slope.
• Zero crossings — where the waveform changes sign.
• Crossing interval — how much time passes between zero crossings.
• Crossing rate — how often crossings occur.
• Clip runs — how long a signal remains at or near a ceiling.
• Running extrema — reusable minimum and maximum accumulation.

None of these primitives knows what a mix is supposed to sound like.

They simply measure the signal.

That distinction matters because the same SlewRate primitive can help characterize a snare transient, detect a click, evaluate distortion, inspect an oscillator, analyze aliasing, or contribute to a future mastering meter.

Time is a separate concern

Measurements become more useful when they are aggregated over meaningful time windows.

Instead of hard-coding a particular number of samples, KahuStack DSP will use time-based analysis windows that remain consistent at 44.1, 48, 96, or 192 kHz.

Those windows can produce reusable frames containing measurements such as:

peak
maximum slew
maximum crossing interval
crossing rate
clip statistics

The audio engine produces the measurements. The user interface merely displays them.

That makes the system deterministic and keeps analysis independent from screen refresh rate.

Distribution matters as much as magnitude

This is the part we find most interesting.

A track that reaches the same peak over and over is different from a track whose meaningful peaks occur across a wide range of intensities.

Two signals may have the same maximum slew but very different patterns of transient activity.

Two bass-heavy signals may have similar low-frequency energy while producing very different zero-crossing behavior.

So the second major part of the library will deal with distributions.

Our initial inventory includes:

• fixed histograms
• decaying or “leaky” histograms
• distribution coverage
• distribution spread
• normalized entropy
• event density
• configurable bin weighting
• joint two-dimensional histograms
• feature-balance measurements

These primitives let us ask better questions.

Not just:

How high did this value get?

but:

How frequently did meaningful events happen?

How broadly were those events distributed?

How varied was the recent behavior?

Which combinations of features occurred together?

Entropy gives us a useful new measurement

One especially useful addition is distribution entropy.

If nearly every observed event falls into one narrow range, entropy is low.

If events are spread broadly across many meaningful ranges, entropy rises.

That gives us a mathematically understandable measurement for something audio engineers often hear but do not have a convenient meter for: event diversity.

For example, a heavily limited signal may remain loud while losing variation in transient amplitude. A peak meter still reports a healthy-looking level. An event-distribution analyzer can show that the signal has become much more uniform.

That does not make one result automatically better than another, but it gives the engineer new information.

The primitive inventory

The first KahuStack DSP analysis inventory is intentionally broad.

Measurement primitives

SampleDeltaTracker
SamplePeak
RunningMax
RunningMin
MinMax
SlewRate
ZeroCrossingDetector
CrossingIntervalTracker
CrossingRate
ClipRunDetector

Time and aggregation

WindowScheduler
WindowAccumulator
WindowedPeak
WindowedMaxSlew
WindowedCrossingRate
WindowedMaxCrossingInterval
WindowedClipStatistics
SignalActivityFrame

Distribution analysis

FixedHistogram
LeakyHistogram
HistogramDecay
BinWeighting
DistributionCoverage
DistributionEntropy
DistributionSpread
JointHistogram

Derived analysis

EventDensity
FeatureBalance
ActivityDimension
ClipActivity
ActivityProfile

Each piece is deliberately narrow.

The final tools become compositions of these pieces rather than giant special-purpose analyzers.

Why Rust is a good fit

These measurements are ideal Rust DSP components.

They can use:

• fixed-size storage
• const generics
• strongly typed units
• explicit state
• deterministic processing
• allocation-free audio paths
• compile-time channel and histogram sizes where useful

A histogram can be:

FixedHistogram::<16>

and a two-dimensional feature map can be:

JointHistogram::<16, 16>

with bounded memory and no allocation in the audio thread.

The same implementation can serve native plugins, command-line analysis, KahuStack applications, and WebAssembly.

Why strongly typed units matter

Audio analysis mixes many quantities that look like ordinary floating-point numbers but are not interchangeable.

A peak amplitude is not a duration.

A crossing interval is not a frequency.

A sample delta is not the same measurement as a sample-rate-normalized slew rate.

So the library will continue KahuStack DSP’s strongly typed approach with concepts such as:

LinearAmplitude
DbFs
SampleRate
SampleCount
Seconds
SampleDelta
AmplitudePerSecond
CrossingInterval
CrossingRate
ClipDuration
Normalized
Occupancy
AnalysisTimestamp

The type system becomes part of the correctness model.

What this enables

The immediate inspiration is metering, but the long-term value is much larger.

These primitives can support:

• compressor development
• limiter testing
• clipper analysis
• transient processing
• saturation characterization
• oscillator QA
• anti-aliasing research
• click and discontinuity detection
• reference matching
• waveform rendering
• MANA synth telemetry
• Voxaliber analysis
• automated DSP tests
• WASM audio testbenches

That is why we are building the primitives first.

A future KahuStack activity meter may eventually combine amplitude activity, transient activity, low-frequency temporal activity, and clipping behavior into a single visual analysis tool.

But that meter will be only one consumer of the library.

The real product is the analysis foundation underneath it.

The larger goal

KahuStack DSP is increasingly becoming a library of reusable DSP ideas rather than a collection of isolated effects.

Audio analysis should follow the same principle.

Instead of embedding measurement logic inside one compressor, one synth, one waveform display, and one meter, we can establish common primitives with well-defined units, permanent tests, and predictable behavior.

Then new tools can be built by composition.

That gives us a cleaner codebase, better testability, more consistent measurements, easier WASM integration, and a much stronger foundation for future audio research.

The core idea is simple:

Measure the signal once, define the measurement clearly, and make it reusable everywhere.