Repository navigation
OfflineAudioContext Incremental Rendering #4473
Description
Specification
https://webaudio.github.io/web-audio-api/#dom-offlineaudiocontext-startrendering
Description
Modifies OfflineAudioContext.startRendering to accept an optional chunkSize argument that allows the audio graph data to be incrementally processed rather than allocating the whole audio buffer up front. Without this feature, all the audio needs to be rendered one-shot in a single AudioBuffer object. By incrementally delivering the data using data chunks, there is no need to have high memory requirements for the user's machine when processing high amounts of data.
Documentation
Demo: https://gabrielsanbrito.github.io/demo_pages/oac-incremental-rendering/
Explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/OfflineAudioContext/explainer.md
Browser support
Implementation under way in Chromium with main functionality already implemented behind a feature flag.
Activity
Rutujakirad commentedon Oct 6, 2026
Hi @gabrielsanbrito,
I have opened a PR for this: #4475
Happy to make any changes if needed. Thanks!
ddbeck commentedon Oct 12, 2026
Thanks for filing this issue, @gabrielsanbrito. I'm going to take some notes here to help mint this feature (#4475 jumped ahead of the process a little). It's not required, but your review of this comment would be welcome.
Name, ID, and description
"OfflineAudioContext Incremental Rendering" sounds natural to me.
As an addition to the API represented by
offline-audio-context(source, dist), this would have the IDoffline-audio-context-incremental-rendering.The description here is a bit challenging, since the change here is (from user code perspective) an anonymous positional argument. In our style, we try to name the entry point for a feature, then describe what can be done with it and, if possible, the benefit of doing so. Does something like this make sense?
Support data
This appears to relate to https://chromestatus.com/feature/5109900936085504.
Upstream, I expect the browser compat data to get
close()data automatically, but we won't get automatic detection of the chunk size arg. I've sent openwebdocs/mdn-bcd-collector#3462 to try to figure that out.gabrielsanbrito commentedon Oct 15, 2026
@ddbeck LGTM % nit below,
I think I would just slightly modify this clause "which limits the length of the returned AudioBuffer". If written that way, I am afraid that it might convey the meaning that
chunkSizeis a hint to the API, when it isn't. What about the version below?"The
startRendering()method of theOfflineAudioContextAPI accepts an optional chunk size argument, which determines the number of sample-frames to render in aAudioBuffer. You can use this to process audio incrementally, reducing the memory required to process high amounts of data."ddbeck commentedon Oct 16, 2026
@gabrielsanbrito thank you, that's very helpful! We'll get this feature added soon.