v1.2.5

Download

Ready to run - the filters are already inside. Unzip, run aura-engine.exe, drop a track on it. The app opens on the filter that came with it.

Bundle	Filter	Output rates	Size
Starter	1M taps	every FS multiplier (FS2-FS16)	134 MB	Download
Standard	10M taps	FS8 (352.8 / 384 kHz)	326 MB	Download
Reference	30M taps	FS8 (352.8 / 384 kHz)	966 MB	Download

Unzip more than one into the same folder and the app offers every tap count you have.

Already have the filters, or want to build from source? The plain app zip is below, and the individual filter packs are on the 1.0.0 release.

Checksums (SHA-256)

5bae7b41c3d30ba54a6ff3c7ab21b51335d86cdc4f7bf71413c50bfab737a43f  aura-engine-v1.2.5-bundle-1M-windows-x64.zip
89040d091b3bf0edb22c9c06f9c7b2c1afc1b522928b03b7efc7029448e59145  aura-engine-v1.2.5-bundle-10M-windows-x64.zip
cfd81a7190f4cbc53cc5baf5bf11a4a33798e88a5b3a85dea84a6ac948313f75  aura-engine-v1.2.5-bundle-30M-windows-x64.zip

What changed in 1.2.5

A card out of room is an answer, not a dead process.

Seventeen crash reports over two days, all the same one: Not enough memory left, raised against the buffers a single GPU convolver owns. That is already
the version where the app was supposed to move to the CPU and finish the file.

1.2.4 made the absence of a device a value. It did not make the device's
refusal one. The decision is taken once, before a batch starts, and never
revisited; an allocation that failed part-way through went to wgpu's handler for
errors nobody caught, and that handler panics. The worker died where the card
had merely said no.

What is actually being asked for: 10M taps at FS8 is a 1.25M-tap polyphase
sub-filter, and one convolver that size needs 544 MB of video memory. A file
that fits in memory builds them one at a time. A file long enough to be
processed in segments holds all eight phases at once. The only thing standing in
the way of that was an 11 GB budget written into the source — a number that
never had anything to do with the card in the machine.

Now a refusal is recorded rather than fatal: that filter is built on the CPU
instead, and the batch finishes. The fallback is per phase, so a card that fills
up part-way keeps the phases it already holds on the GPU, and the refusal is
remembered for the rest of the batch rather than repeated once per file.

Falling back costs time and nothing else: the CPU path is the f64 reference the
GPU path is verified against, so what is given up is the wait, not the result.

Reported by @Gramofonik in discussion #2.