v158 · web audio · offline rendering
The memory math
The motivating bug report is arithmetic: frames × channels × 4 bytes, allocated before the first sample renders. Dial in a project below and compare the classic up-front allocation against the bounded peak of a chunked pull loop — then run a real, deliberately small render in this browser and measure what actually came back.
Chrome targets incremental rendering for Chrome 158 behind the OfflineAudioContextIncrementalRendering runtime flag (--enable-blink-features=OfflineAudioContextIncrementalRendering, or chrome://flags/#enable-experimental-web-platform-features). The calculator is pure arithmetic from the spec's float32 sample format; the measured render below is real on every build.
The calculator
Classic: one AudioBuffer up front
…
Allocated before rendering begins, held until you drop the buffer.
Chunked: peak of one chunk
…
One chunk in flight; encode it, release it, pull the next.
…
Measure a real (small) render in this browser
Ten seconds of stereo 48 kHz — small enough to be safe anywhere. The page renders it for real, times it, and reports the bytes the resulting buffer(s) actually hold. On a Chrome 158 build it pulls 4096-frame chunks and reports the peak chunk size; on an older build it reports the single full-size buffer the classic path allocated. Nothing here fakes a measurement of a two-hour project — allocating gigabytes to prove a point about allocating gigabytes would take the tab down.
the arithmetic, spelled out
// float32 samples, planar per channel:
bytes = frames × channels × 4
// 2 h stereo @ 48 kHz, classic:
7200 s × 48000 × 2 × 4 = 2 764 800 000 B ≈ 2.76 GB // before rendering starts
// same project, chunked @ 4096 frames:
4096 × 2 × 4 = 32 768 B = 32 KB // peak, per pull