[Medium] Audio decode allocates the whole file in memory (up to ~1 GiB)

[adilei]

Severity

Medium — unbounded-ish memory use on long recordings (potential OOM).

Location

electron/audio/decode.ts:10 — const MAX_SAMPLES = 256 * 1024 * 1024; combined with the whole-file decode path in electron/audio/capture-preload.cjs.

Mechanism

Decoding loads the entire narration track into a single Float32Array. The cap is 256M samples × 4 bytes ≈ 1 GiB for one buffer (~4.6h at 16 kHz), and the intermediate decode holds the full file too. There is a DECODE_TIMEOUT_MS guard, but not a memory/streaming guard.

Impact

Long sessions can spike main/helper memory and OOM on lower-RAM machines.

Suggested fix

Decode/downmix incrementally (stream in CHUNK_SAMPLES-sized windows and append/flush), or lower the cap and fail fast with a clear message when exceeded rather than allocating up to ~1 GiB.

Regression test to add (npm test)

Unit test that a synthetic over-cap input is rejected/handled gracefully (no unbounded allocation), and that chunked decode reassembles a known short signal correctly. Deterministic; outside the evals/ scope.