Refactor/reuse buffers by mdydek · Pull Request #1283 · software-mansion/react-native-audio-api

mdydek · 2026-09-11T11:27:38Z

Direct continuation of the work from #1281, different mental model, still addresses #1263

Introduced changes

Screens from https://github.com/WentTheFox/AudioApiLeakRepro
before:

after:

to best understand new approach we will split the buffer lifetime to 3 parts: before setting him in absn, after setting but before starting, after start

before setting: audiobuffer is a one place both for the js and native, each calls and data is shared between
after setting: each getChannelData gets you the copy of the new data, which could affect the absn, but only after the start we will respect possible changes
after start: acquire the content, invalidate older buffers so the js cannot change the data played in between and the node is repointed to the possibly changed buffers

by implementing this approach usual use case of the audiobuffersourcenode and creating new node with already present buffer allocates only memory for the metadata of the node

Checklist

Linked relevant issue
Updated relevant documentation
Added/Conducted relevant tests
Performed self-review of the code
Updated Web Audio API coverage
Added support for web
Updated old arch android spec file

…y setBuffer AudioBufferSourceNodeHostObject::setBuffer() deep-copied the entire AudioBuffer on every `.buffer = x` reassignment, even when reassigning the exact same underlying buffer. That's exactly what seeking is. A live AudioBufferSourceNode can't be repositioned, so the standard pattern is to stop/disconnect it and create a fresh source node wrapping the already-decoded buffer at a new offset. Every seek therefore triggered a full, unnecessary copy of the whole track's PCM data. On a 4-minute stereo buffer this is a real full-size copy (~85MB) per seek. The old copy isn't freed until its replacement's scheduled audio event actually runs, so repeated rapid seeking accumulates full-size buffers faster than the audio thread can free the previous ones. The growing native heap eventually crashes the app via a Hermes GC OOM once it can no longer find room to grow the JS heap. This caches the defensive copy on the JS-visible AudioBufferHostObject and reuses it across repeated reassignments of the same buffer. The cache is invalidated only when the buffer's data could actually have been mutated: copyToChannel, or a live getChannelData() view having escaped to JS, since JS could write through that view at any later time. This keeps the exact copy-on-first-touch semantics the original code needed for pitch-correction and mutation safety, while making the "same buffer, many source nodes" pattern free after the first copy instead of paying for a fresh copy on every single reassignment. The caching logic lives in a new, standalone ImmutableBufferCache utility rather than directly in AudioBufferHostObject, because HostObjects/*.cpp is excluded from this project's C++ test suite (see common/cpp/test/CMakeLists.txt) and a plain utility class can be unit tested without a jsi::Runtime. Also documents this in the best-practices guide. The existing "reuse the same AudioBuffer across nodes" guidance was already correct, but silently expensive before this fix; it is now actually cheap as advertised. Verified: - The library's own C++ test suite still passes in full, plus 4 new unit tests for ImmutableBufferCache covering reuse, distinct-copy identity, and both invalidation paths (420/420 total). - A minimal repro app (creating a fresh AudioBufferSourceNode/GainNode pair wrapping the same AudioBuffer every ~150ms, simulating rapid seeking) went from ~71MB leaked per seek (visibly crashing within ~60 iterations) to no measurable per-seek growth across three consecutive 60-iteration runs, measured via `adb shell dumpsys meminfo` before/after/+30s-settled. - A real app using this pattern for playback seeking held native heap flat (Android, Samsung Galaxy S24+) across ~200 rapid seeks that previously crashed within a similar span. Fixes #1263

github-actions · 2026-09-11T11:34:37Z

WPT non-regression comparison

PASS — no regressions · 1 improved section(s) · overall 3427 → 3429 (+2)

Spec section	Base pass	Head pass	Delta
AudioBuffer	140	142	+2

Unchanged sections (27)

Spec section	Base pass	Head pass
Processing model	1	1
Other	56	56
AnalyserNode	138	138
AudioBufferSourceNode	220	220
AudioContext	58	58
AudioNode	261	261
AudioParam	680	680
BiquadFilterNode	275	275
ChannelMergerNode	30	30
ChannelSplitterNode	7	7
ConstantSourceNode	64	64
ConvolverNode	178	178
DelayNode	127	127
DestinationNode	0	0
DynamicsCompressorNode	4	4
GainNode	15	15
IIRFilterNode	87	87
MediaElementAudioSourceNode	0	0
MediaStreamAudioDestinationNode	1	1
MediaStreamAudioSourceNode	0	0
OfflineAudioContext	35	35
OscillatorNode	104	104
PannerNode	727	727
PeriodicWave	33	33
ScriptProcessorNode	0	0
StereoPannerNode	104	104
WaveShaperNode	82	82

_{Baseline: ba0d65b1130521f26389cb736fde392022ab11a6 · Candidate: 51c8f02188a754ef181beaf9674c38e324d91e0c}

_{Workflow run · this comment is updated on every push.}

SomePersonFromMars · 2026-10-08T19:06:03Z

 void AudioBufferSourceNode::setBuffer(
    const std::shared_ptr<AudioBuffer> &buffer,
    const std::shared_ptr<DSPAudioBuffer> &audioBuffer) {
+  if (!swapBuffers(buffer, audioBuffer)) {
+    return;
+  }
+
+  loopEnd_ = buffer_ == nullptr ? 0 : buffer_->getDuration();
+}
+
+void AudioBufferSourceNode::replaceBufferContent(
+    const std::shared_ptr<AudioBuffer> &buffer,
+    const std::shared_ptr<DSPAudioBuffer> &audioBuffer) {
+  swapBuffers(buffer, audioBuffer);
+}


What's the actual difference between setBuffer() and replaceBufferContent()? Why doesn't the latter update channelCount_ and loopEnd_? Is it safe in general? If not, should this method be public?

update of loopEnd_ is needed because with new buffer stale old value would be in the incorrect state. Whereas, raw replaceBufferContent function was needed, because if we returned channelData to JS, during acquiring content we copy only the buffer content. But right now looking at it, I think it is completely safe to also update loopEnd_ in the same function, which would leave us with only one function setBuffer that does everything

SomePersonFromMars · 2026-10-08T19:31:59Z

This host object seems to have gained new responsibilities:

Preparation of buffers.

Operation of "acquiring the buffer".

Probably more...

I see that all those responsibilities at the first glance depend on host objects and JS runtime, but my intuition is that they shouldn't. I don't think that host objects should do the business logic.

SomePersonFromMars · 2026-10-08T19:39:06Z

Similarly to AudioBufferSourceNodeHostObject, this host object seems to gained too many responsibilities too. Can't they be moved downwards? In particular, host object shouldn't:

Copy-on-write, handle versioning, etc.

VikalpP · 2026-10-11T13:55:14Z

I ran the reproduction from #1340 against this branch, in case the numbers are useful while it is still in review.

Tested: PR head 51c8f02 against its base on main (ba0d65b), plus the 0.13.6 release as a reference. iOS 27 simulator, debug build, Hermes. Input is 131 s of stereo 48 kHz audio, raw float32 PCM 47.97 MiB. Each variant was launched twice and gave identical js_externalBytes.

HermesInternal.getInstrumentedStats().js_externalBytes, MiB:

Step	0.13.6	main (`ba0d65b`)	main + this PR
`decodeAudioData`	119.9 (+2.00x)	119.9 (+2.00x)	72.0 (+1.00x)
first source, `.buffer = buf`, `connect`	215.9 (+2.00x)	216.2 (+2.01x)	120.3 (+1.01x)
5 more sources, same `buf`	695.6 (+10.00x)	697.8 (+10.04x)	362.0 (+5.04x)
all references dropped	191.9	192.3	96.3
loop x30 (decode, new source, assign, drop), min / max	408 / 600	409 / 601	217 / 313

Process RSS, MB:

	0.13.6	main	main + this PR
peak during the loop	about 2040	about 2050	about 680
10 s after the loop	about 1920	about 1975	about 535

So the real saving is large: RSS in the loop drops to about a third, and the decode is now reported at its actual size.

One thing that still stands out: every source.buffer = buf adds one full buffer to the reported external memory (+1.0x each), although the storage is now shared and nothing new is allocated. That looks like it comes from the setter still crediting getSizeInBytes() per node:

react-native-audio-api/packages/react-native-audio-api/common/cpp/audioapi/HostObjects/sources/AudioBufferSourceNodeHostObject.cpp

Lines 158 to 162 in 51c8f02

    
           auto bufferHostObject = args[0].getObject(runtime).asHostObject<AudioBufferHostObject>(runtime); 
        
           thisValue.asObject(runtime).setExternalMemoryPressure( 
        
               runtime, getMemoryPressure() + bufferHostObject->getSizeInBytes()); 
        
           setBuffer(bufferHostObject);

For a player that creates a new source on every play or seek, Hermes would still see that figure grow per source until the nodes are collected, even with flat real memory. After dropping all references 96.3 MiB (2.0x) remained reported, unchanged 5 s later.

start() and stop() ran without errors on this branch. I did not check the audio output by ear.

Repro: https://github.com/VikalpP/audio-api-external-memory-repro

WentTheFox and others added 3 commits September 10, 2026 13:06

feat: acquire the content in absn

00f51c5

refactor: new model of acquiring the buffer

0ca46b8

mdydek added the refactor Code restructuring without altering external behavior or fixing bugs label Sep 11, 2026

mdydek mentioned this pull request Sep 11, 2026

fix(android/ios): cache AudioBuffer copy instead of recopying on every setBuffer #1281

Closed

4 of 7 tasks

mdydek marked this pull request as draft September 11, 2026 11:49

fix: remove unnecesary allocation in the constructor

017dcf8

mdydek marked this pull request as ready for review September 11, 2026 11:56

WentTheFox mentioned this pull request Sep 11, 2026

SIGSEGV on JS thread's own event loop under rapid AudioBufferSourceNode + onEnded churn #1285

Closed

mdydek requested a review from maciejmakowski2003 September 24, 2026 10:31

github-actions Bot added the conflicts This PR has conflicts with the base branch. label Oct 5, 2026

Merge branch 'main' into refactor/reuse-buffers

e47aa7d

github-actions Bot removed the conflicts This PR has conflicts with the base branch. label Oct 5, 2026

SomePersonFromMars reviewed Oct 8, 2026

View reviewed changes

SomePersonFromMars requested changes Oct 8, 2026

View reviewed changes

mdydek added 3 commits October 9, 2026 14:18

refactor: cleanup of the implementation after review

5bd8a0b

Merge branch 'main' into refactor/reuse-buffers

0b76000

refactor: corrected version, less copies

51c8f02

VikalpP mentioned this pull request Oct 11, 2026

Memory grows every time the same AudioBuffer is assigned to a new source node (iOS) #1340

Open

Navigation Menu

Repository navigation

Refactor/reuse buffers - #1283

Refactor/reuse buffers#1283
mdydek wants to merge 8 commits into
mainfrom
refactor/reuse-buffers

mdydek commented Sep 11, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 11, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

SomePersonFromMars Oct 8, 2026

Uh oh!

mdydek Oct 9, 2026

Uh oh!

SomePersonFromMars Oct 8, 2026 •

edited

Loading

Uh oh!

SomePersonFromMars Oct 8, 2026 •

edited

Loading

Uh oh!

VikalpP commented Oct 11, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

mdydek commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Introduced changes

Checklist

Uh oh!

github-actions Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

WPT non-regression comparison

Uh oh!

Uh oh!

Uh oh!

SomePersonFromMars Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

mdydek Oct 9, 2026

Choose a reason for hiding this comment

Uh oh!

SomePersonFromMars Oct 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SomePersonFromMars Oct 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VikalpP commented Oct 11, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mdydek commented Sep 11, 2026 •

edited

Loading

github-actions Bot commented Sep 11, 2026 •

edited

Loading

SomePersonFromMars Oct 8, 2026 •

edited

Loading

SomePersonFromMars Oct 8, 2026 •

edited

Loading