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

Description

On iOS with Hermes, the external memory reported to the JS engine for decoded audio is much larger than the audio itself, and it grows with every AudioBufferSourceNode that is given the same AudioBuffer:

decodeAudioData raises HermesInternal.getInstrumentedStats().js_externalBytes by 2x the raw float32 PCM size of the decoded buffer.
Every source.buffer = buf assignment raises it by another 2x of the raw PCM size, even though it is the same buffer each time.
After all references are dropped, 4x of the raw PCM size stays reported (no globalThis.gc in this build; still there 5 seconds later).

For a 131 s stereo 48 kHz input (raw PCM 47.97 MiB), one decode plus six source nodes sharing that buffer report 671.6 MiB of external memory, 14x the PCM size.

A player that creates a new source node on every play, seek or chunk change, which as far as I know is the usual pattern since a source can only be started once, reaches Hermes' limit quickly. In our app a randomized play/pause/seek stress run ends in a Hermes out-of-memory abort after about 3.5 minutes on 0.13.6, with js_externalBytes at about 3.4 GB and the JS heap under 100 MB:

EXC_BAD_ACCESS (SIGSEGV), thread com.facebook.react.runtime.JavaScript
hermes::hermes_fatal
hermes::vm::GCBase::oom
hermes::vm::HadesGC::OldGen::allocSlow
hermes::vm::HadesGC::youngGenCollection

Comparison with 0.10.3, measured in the same app on React Native 0.81.5 (the repro below cannot run 0.10.x because it uses React Native 0.86): decoding one chunk and assigning it to one source reported +100.6 MB on 0.10.3 and +201.2 MB on 0.13.6, and the same stress run took about twice as long to hit the limit on 0.10.3 (7 min 48 s versus 3 min 35 s). Process RSS grew by about the same amount for that chunk on both versions (about 150 MB). So the per-assignment cost appears to have been introduced after 0.10.3; the repro shows identical numbers on 0.12.2 and 0.13.6.

This looks related to #1263 (repeated seek with the same AudioBuffer leaks native heap on Android, ending in a Hermes GC OOM) and to the open PR #1283, and possibly to #1266. What this report adds: it reproduces on iOS, it gives a minimal app with per-step numbers, and it shows the amounts reported to Hermes through external memory accounting, including the 2x factor on a plain decode and the 4x that remains after the references are dropped. Happy to have it closed as a duplicate of #1263 if you prefer to track it there.

Steps to reproduce

Clone the repro, npm install, npx expo run:ios.
Press "Run". The app builds a 131 s stereo 48 kHz PCM16 WAV in memory and then, waiting 1 s after each step, reads HermesInternal.getInstrumentedStats().js_externalBytes.
Compare each step's increase with the raw PCM size (buf.length * buf.numberOfChannels * 4).

Result on 0.13.6 (identical on two launches, and identical on 0.12.2), in MiB:

Step	externalBytes	delta	delta / raw PCM
baseline	0.0
WAV `ArrayBuffer` created (24.0 MiB)	24.0	+24.0	0.50
`new AudioContext()`	24.0	0.0	0.00
`await ctx.decodeAudioData(wav)`	119.9	+95.9	2.00
`createBufferSource()`, `src.buffer = buf`, `connect`	215.9	+95.9	2.00
`src.start()`, `src.stop()` after 1 s	215.9	0.0	0.00
5 more sources, same `buf` assigned, not started	695.6	+479.7	10.00
all references dropped	191.9	-503.7	-10.50
5 s later	191.9	0.0	0.00

"Loop x30" in the same app (decode, new source, assign, drop, 30 times) cycles between 408, 504 and 600 MiB and drops back every third iteration, so in this simple loop the collector keeps up. Process RSS still climbed from about 450 MB to about 1.8 GB over that loop.

Expected: assigning an existing AudioBuffer to another source node should not add a full buffer's worth of memory, and the amount reported to the engine should match what is actually held.

Snack or a link to a repository

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

React Native Audio API version

0.13.6 (same numbers on 0.12.2; not present on 0.10.3)

React Native version

0.86.3 (Expo SDK 57.0.27)

Platforms

iOS

JavaScript runtime

Hermes

Workflow

Expo Dev Client

Architecture

Fabric (New Architecture)

Build type

Debug mode

Device

iOS simulator

Device model

iPhone 18 Pro (iOS 27.0), Xcode 27.0

Acknowledgements

Yes

Code references for the three numbers above, from reading the source at the 0.13.6 tag (a3148fe). Nothing new was measured, and where the code does not explain a number I say so.

A. The 2x on decode is the size formula, not a second copy

AudioBufferHostObject::getSizeInBytes() multiplies the PCM size by 2, and the decoder credits that value to the JS object it returns:

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

Lines 32 to 35 in a3148fe

    
           [[nodiscard]] size_t getSizeInBytes() const { 
        
             // *2 because every time buffer is passed we create a copy of it. 
        
             return audioBuffer_->getSize() * audioBuffer_->getNumberOfChannels() * sizeof(float) * 2; 
        
           }

react-native-audio-api/packages/react-native-audio-api/common/cpp/audioapi/HostObjects/utils/AudioDecoderHostObject.cpp

Lines 40 to 46 in a3148fe

    
           auto audioBufferHostObject = std::make_shared<AudioBufferHostObject>(result.unwrap()); 
        
           return [audioBufferHostObject = std::move(audioBufferHostObject)]( 
        
                      jsi::Runtime &runtime) -> std::variant<jsi::Value, std::string> { 
        
             auto jsiObject = jsi::Object::createFromHostObject(runtime, audioBufferHostObject); 
        
             jsiObject.setExternalMemoryPressure(runtime, audioBufferHostObject->getSizeInBytes()); 
        
             return jsiObject;

For this input: 6288000 frames x 2 channels x 4 bytes x 2 = 100,608,000 bytes = 95.9 MiB. I found only one long-lived AudioBuffer on the decode path, so as far as I can tell 1x is held and 2x is reported.

B. Each assignment is a real 1x copy, reported as 2x

The host setBuffer credits the same 2x value to the source node's JS object, then deep-copies the PCM (the AudioBuffer copy constructor allocates new channel storage):

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

Lines 144 to 148 in a3148fe

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

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

Lines 177 to 179 in a3148fe

    
           } else { 
        
             copiedBuffer = std::make_shared<AudioBuffer>(*buffer); 
        
           }

react-native-audio-api/packages/react-native-audio-api/common/cpp/audioapi/utils/AudioBuffer.hpp

Lines 46 to 54 in a3148fe

    
           AlignedAudioBuffer(const AlignedAudioBuffer &other) 
        
               : numberOfChannels_(other.numberOfChannels_), 
        
                 sampleRate_(other.sampleRate_), 
        
                 size_(other.size_) { 
        
             channels_.reserve(numberOfChannels_); 
        
             for (const auto &channel : other.channels_) { 
        
               channels_.emplace_back(std::make_shared<AlignedAudioArrayBuffer<Alignment>>(*channel)); 
        
             } 
        
           }

That matches the +95.9 MiB per assignment.

C. What releases it

I found no code that lowers the reported bytes other than the credited JS objects being garbage collected; setBuffer(null) does not reset the value. The copy is owned by the native node, which is held by its host object and by the graph manager's sourceNodes_. It is handed to the destructor thread only when a render pass finds use_count() == 1 on an unscheduled or finished node, so only after the host object has been finalized:

react-native-audio-api/packages/react-native-audio-api/common/cpp/audioapi/core/utils/AudioGraphManager.h

Line 154 in a3148fe

return node.use_count() == 1 && (node->isUnscheduled() || node->isFinished());

The 4.00x that remains equals two objects still carrying a 2x credit (695.6 - 24.0 - 5 x 95.9 = 191.9 MiB). Which two, and why the loop falls back every third iteration, depends on Hermes GC timing. I could not determine either from this library's code.

D. When it changed

The * 2 was added in #942 (0a23a8e), first released in 0.12.0. At 0.10.3 the formula was 1x and the node already made a full copy on every assignment:

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

Lines 32 to 35 in ceb44f5

    
           [[nodiscard]] inline size_t getSizeInBytes() const { 
        
             return audioBuffer_->getLength() * audioBuffer_->getNumberOfChannels() * 
        
                    sizeof(float); 
        
           }

react-native-audio-api/packages/react-native-audio-api/common/cpp/audioapi/core/sources/AudioBufferSourceNode.cpp

Lines 84 to 85 in ceb44f5

    
           buffer_ = buffer; 
        
           alignedBus_ = std::make_shared<AudioBus>(*buffer_->bus_);

That fits what we measured in our app: half the reported bytes on 0.10.3, about the same RSS growth. It also means I need to correct the description above: the per-assignment copy is not new. It was already there in 0.10.3, and what changed in 0.12.0 is that the reported size doubled.

Relation to #1283

At its current head (51c8f02), #1283 drops the * 2 and replaces the copy with shared channel storage, so from reading it should remove both the decode 2x and the real per-assignment copy. The setter there still credits one full buffer size to every source node, so reported external memory would still grow by 1x per assignment even though nothing new is allocated. This is from reading only; I have not run that branch.

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);

Navigation Menu

Repository navigation

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

Description

Steps to reproduce

Snack or a link to a repository

React Native Audio API version

React Native version

Platforms

JavaScript runtime

Workflow

Architecture

Build type

Device

Device model

Acknowledgements

A. The 2x on decode is the size formula, not a second copy

B. Each assignment is a real 1x copy, reported as 2x

C. What releases it

D. When it changed

Relation to #1283

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	[[nodiscard]] size_t getSizeInBytes() const {
	// *2 because every time buffer is passed we create a copy of it.
	return audioBuffer_->getSize() * audioBuffer_->getNumberOfChannels() * sizeof(float) * 2;
	}

	auto audioBufferHostObject = std::make_shared<AudioBufferHostObject>(result.unwrap());

	return [audioBufferHostObject = std::move(audioBufferHostObject)](
	jsi::Runtime &runtime) -> std::variant<jsi::Value, std::string> {
	auto jsiObject = jsi::Object::createFromHostObject(runtime, audioBufferHostObject);
	jsiObject.setExternalMemoryPressure(runtime, audioBufferHostObject->getSizeInBytes());
	return jsiObject;

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

	setBuffer(bufferHostObject->audioBuffer_);

	} else {
	copiedBuffer = std::make_shared<AudioBuffer>(*buffer);
	}

	AlignedAudioBuffer(const AlignedAudioBuffer &other)
	: numberOfChannels_(other.numberOfChannels_),
	sampleRate_(other.sampleRate_),
	size_(other.size_) {
	channels_.reserve(numberOfChannels_);
	for (const auto &channel : other.channels_) {
	channels_.emplace_back(std::make_shared<AlignedAudioArrayBuffer<Alignment>>(*channel));
	}
	}

	[[nodiscard]] inline size_t getSizeInBytes() const {
	return audioBuffer_->getLength() * audioBuffer_->getNumberOfChannels() *
	sizeof(float);
	}

	buffer_ = buffer;
	alignedBus_ = std::make_shared<AudioBus>(*buffer_->bus_);

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

	setBuffer(bufferHostObject);

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

Description

Description

Steps to reproduce

Snack or a link to a repository

React Native Audio API version

React Native version

Platforms

JavaScript runtime

Workflow

Architecture

Build type

Device

Device model

Acknowledgements

Activity

VikalpP commented on Oct 11, 2026

A. The 2x on decode is the size formula, not a second copy

B. Each assignment is a real 1x copy, reported as 2x

C. What releases it

D. When it changed

Relation to #1283

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions