AudioBufferQueueSourceNode plays at ~3× speed with heavy static on iOS (regression in 0.12.0+, clean on 0.11.7)

[marcospgp]

Description

AudioBufferQueueSourceNode plays streamed 24 kHz LINEAR16 PCM at ~3× the correct rate with heavy continuous static layered on top, on iOS device (real iPhone) AND iOS Simulator. The voice is intelligible but sped up and noisy.

Downgrading the library to 0.11.7 fully restores clean playback on the same device, same JS code, same audio session config, same source data. The bug is therefore a regression introduced between 0.11.7 and 0.12.1. There is at least one other 0.12.0+ regression reported (#1062, StreamerNode SIGABRT), which suggests the queue/streamer paths got reworked in that range.

Observed pace ratio

I instrumented onPositionChanged against wall clock for one TTS-streaming session (24 kHz LINEAR16 PCM, ~50 ms chunks, base64 over WebSocket, fed via enqueueBuffer on an AudioBufferQueueSourceNode).

[init]   audioCtxSampleRate=24000, devicePreferredSampleRate=48000, requestedSampleRate=24000
[chunk0] bytes=20160, frames=10080, bufferSampleRate=24000, audioCtxSampleRate=24000, expectedChunkDurationSec=0.420, audioCtxState=running
ERROR  NotSupportedError: The number of frames provided (0) is less than or equal to the minimum bound (0)   ← fires once, right after the first chunk
[pace]  wall=0.514, audioPos=1.184, ratio=2.304
[pace]  wall=1.026, audioPos=2.702, ratio=2.634
[pace]  wall=1.527, audioPos=4.220, ratio=2.764
[pace]  wall=2.038, audioPos=5.738, ratio=2.816
[pace]  wall=2.548, audioPos=7.256, ratio=2.848
[pace]  wall=3.054, audioPos=8.774, ratio=2.873
[pace]  wall=3.562, audioPos=10.292, ratio=2.889
[pace]  wall=4.064, audioPos=11.810, ratio=2.906

Steady-state delta: audioPos advances by exactly 1.518 s per 0.5 s of wall time → ratio = 3.036×. The rising-toward-3 trend in the first few samples is just startup latency amortizing (wall clock anchored before the first frame actually emerged from the speaker).

source.playbackRate.value and source.detune.value were checked at construction time: both at their documented defaults (1.0 and 0.0 respectively). No pitchCorrection, no manual playbackRate writes anywhere in our JS.

The NotSupportedError: number of frames provided (0) fires exactly once, right after the first chunk is enqueued. The audio keeps playing through it. I do not know if it's related to the speed/static symptoms or independent, but it is new in 0.12.x. Not present on 0.11.7.

What I have ruled out

• Not the source data. I bypassed the library entirely and wrote the same PCM stream out as a WAV file via a standalone Node script; afplay on the same machine plays it at correct speed with zero static.
• Not the JS code path. Same code on 0.11.7 plays cleanly; only the library version differs.
• Not the iOS audio session category. Same playAndRecord + defaultToSpeaker config under both versions.
• Not Bluetooth / route negotiation. Bug reproduces over built-in iPhone speaker and over wired output.
• Not Voice Processing IO (VPIO). Verified by rebuilding with VPIO disabled. Symptoms unchanged on 0.12.1, still clean on 0.11.7.

Steps to reproduce

1. Install react-native-audio-api@0.12.1.
2. Create an AudioContext({ sampleRate: 24000 }).
3. createBufferQueueSource(), connect to destination, start(0, 0).
4. Stream 24 kHz mono LINEAR16 PCM chunks: decode base64 → Int16 → Float32 → createBuffer(1, frames, 24000) → copyToChannel → enqueueBuffer.
5. Listen on iOS (device or simulator, both reproduce).

Result on 0.12.1: ~3× speed + heavy static. Result on 0.11.7: clean playback at correct speed.

I can't share a runnable Snack repro of the streaming path itself, but the recipe above is the entirety of the relevant call surface. A static-file 24 kHz PCM repro should suffice. If it doesn't reproduce with a single concatenated buffer, the bug is likely in the queue/enqueue path specifically.

React Native Audio API version

0.12.1 (broken). 0.11.7 (works).

React Native version

0.83.6

Expo version

55.0.23

Platforms

iOS (device + simulator both reproduce)

JavaScript runtime

Hermes

Workflow

Expo (development build, not Expo Go)

Architecture

Fabric (New Architecture)

Build type

Debug

Device

iPhone (real device) AND iOS Simulator

Device model

iPhone (current generation, built-in speaker). Same symptom on Simulator.

Acknowledgements

Yes

[closetcaiman]

Hi @marcospgp,
I’ve reproduced the static on my side, though I’m not seeing the 3x speedup. We recently updated QueueBufferSourceNodeprocessing in #1047, which was released in 0.12.2. This refactor fixed a few bugs and may have covered your case. Could you check if the issue persists on the latest version?

[nbarkoch]

Hi @closetcaiman — I’m still able to reproduce this on 0.12.2, but in my case it happens in the regular AudioBufferSourceNode path, not the queue path.

I compared 0.12.2 with 0.11.7, and the relevant difference seems to be around BaseAudioContext::scheduleAudioEvent.

In 0.12.2, when the context is not yet running, the event is executed synchronously:

if (getState() != ContextState::RUNNING) {
  processAudioEvents();
  event(*this); // runs on JS thread, no lock
  return true;
}

Before the first start(), setBuffer can run on the JS thread and write fields like buffer_, audioBuffer_, and channelCount_. Once the engine starts, the audio thread may read that state without synchronization.

In 0.11.7, this path was protected by a Locker mutex around setBuffer / processNode, but that protection seems to have been dropped in the 0.12 rewrite.

This patch fixes the issue for me by always routing the event through the scheduler instead of executing it immediately:

diff --git a/node_modules/react-native-audio-api/common/cpp/audioapi/core/BaseAudioContext.h b/node_modules/react-native-audio-api/common/cpp/audioapi/core/BaseAudioContext.h
--- a/node_modules/react-native-audio-api/common/cpp/audioapi/core/BaseAudioContext.h
+++ b/node_modules/react-native-audio-api/common/cpp/audioapi/core/BaseAudioContext.h
@@ -125,12 +125,12 @@
 
   template <typename F>
   bool scheduleAudioEvent(F &&event) noexcept { // NOLINT(cppcoreguidelines-missing-std-forward)
-    if (getState() != ContextState::RUNNING) {
-      processAudioEvents();
-      event(*this);
-      return true;
-    }
-
+    // Patch for react-native-audio-api#1064: always queue events for the audio
+    // thread; never execute synchronously on the JS thread. The removed branch
+    // ran event handlers (e.g. AudioBufferSourceNode::setBuffer) on the JS
+    // thread when state != RUNNING, leaving node fields exposed to an
+    // unsynchronized read by the audio thread once it starts. 0.11.7 protected
+    // this with a mutex (removed in the 0.12 rewrite); this is the missing
+    // replacement.
     return audioEventScheduler_.scheduleEvent(std::forward<F>(event));
   }

With this change, the issue disappeared for me. Previously I was hitting it on around 1/3 cold launches; after the patch I could no longer reproduce it across 4+ launches on 2 different iOS devices.

Since enqueueBuffer also goes through the same scheduler path, this might be the same root cause as the original issue, just with a slightly different timing window: intermittent in my case, but more consistent in @marcospgp’s case.

[closetcaiman]

Hi @nbarkoch, could you please provide the code for your issue, it would help a lot as I can't reproduce it with mine -> gist with my reproduction.

About your findings:

Once the engine starts, the audio thread may read that state without synchronization.

The code you've highlighted runs only if the getState() != ContextState::RUNNING, so when JS thread enters this branch, Audio thread is not running. There is no race here.

[marcospgp]

Providing more details after some investigation into this issue today. Setup: an Expo iOS app that streams 24 kHz LINEAR16 PCM from a TTS service through AudioBufferQueueSourceNode, with AudioRecorder on the input side under the same shared AudioContext({ sampleRate: 24000 }). The AudioRecorder runs with setVoiceProcessingEnabled:YES for echo cancellation. Reproduces on 0.12.2 on iOS (both physical device and Simulator) with the same ~3x deterministic speedup plus heavy background static.

Below is a diff of 0.11.7 (last known clean for this team, with the same VPIO usage) against 0.12.2 to localize the regression before reaching for a patch. Findings, sorted from "ruled in" to "ruled out":

Architecture: the SPSC scheduler in 0.12.2 looks sound, not broken. The nbarkoch patch proposal to add a Locker around BaseAudioContext::scheduleAudioEvent does not match what is in the source. AudioBufferQueueSourceNodeHostObject::enqueueBuffer/dequeueBuffer/clearBuffers already route every queue mutation through scheduleAudioEvent, which uses a single-producer-single-consumer channel drained by the audio thread inside AudioDestinationNode::renderAudio → context->processAudioEvents() before preProcessGraph. Net effect: queue mutations land on the audio thread, no race, no need for Locker on those operations. AudioBufferQueueSourceNode.cpp still #includes Locker.h but never calls it. That looks like the correct end state given the new scheduler, not an omission. The dropped std::mutex bufferLock_ from AudioBufferBaseSourceNode.h is consistent with the new design, not a regression in isolation.

Render math in BufferProcessorBase::renderBlock is correct at the rate == 1.0 path. output->copy(*buffer, readIndex, writeIndex, toCopy); consume(toCopy); is a 1:1 copy. For this team's config (24 kHz buffer, 24 kHz context, no detune, no pitchCorrection), getComputedPlaybackRateValue returns 1.0 and renderBlock (not renderInterpolated) is dispatched.

IOSAudioPlayer::deliverOutputBuffers pendingSaved_ overflow logic is conservation-correct. Source frames consumed = output frames delivered + pending count, with pending bounded at < RENDER_QUANTUM_SIZE. Walked through several numFrames examples; no accumulating drift.

Format wiring is structurally identical to 0.11.7. Both versions register the source node via initStandardFormatWithSampleRate:registeredSampleRate channels:channelCount and connect:to:mainMixerNode format:format.

So at the layers reviewed, 0.12.2 should produce the same audible output as 0.11.7. It does not. The mechanism is not in the C++ render/queue/scheduler paths or in the format wiring.

Most-likely remaining suspect: a sample-rate mismatch between the source node's registered format and the AVAudioEngine output route after the new lazy materialization path. 0.12.2 introduces:

• Lazy materializeSourceNodeWithId (the source node is created during attachSourceNodeWithRenderBlock and re-created on every engine rebuild via materializeTrackedNodesIfNeeded).
• sessionDeactivationInvalidatedGraph flag that triggers restartAudioEngine → rebuildAudioEngine → materializeTrackedNodesIfNeeded whenever the session is reconfigured.

If at re-attach time [mainMixerNode outputFormatForBus:0] reports a different rate than the source's registered format, and AVAudioEngine fails to insert an SRC for the new format (or inserts one whose direction is unexpected), a 24 kHz source pumped into an 8 kHz sink reads 3x faster. That matches the ~3x speedup numerically (24/8 = 3) and is consistent with reproduction on Simulator (where no bluetooth / VPIO route is involved at all, since iOS Simulator routes through the host Mac's audio at the Mac's hardware rate), provided the source format and the engine output format diverge at any point in the materialization sequence.

This is a hypothesis, not a verified mechanism. The team has not yet captured [engineInputNode outputFormatForBus:0], [mainMixerNode outputFormatForBus:0], and [outputNode outputFormatForBus:0] at each materialization point. If anyone has those diagnostics already wired, that would close it. Otherwise the plan is to wire those NSLogs on the next build pass and follow up.

Current action on the team's side: rolling back to 0.11.7 for now (works cleanly with the same VPIO setVoiceProcessingEnabled:YES patch carried for some time).

[mdydek]

@marcospgp do you by any chance use recorder with 8kHz sample rate?

[marcospgp]

@mdydek No, my recorder is at 16 kHz, not 8 kHz. Exact config (single AudioRecorder in the streaming path):

const recorder = new AudioRecorder();
recorder.onAudioReady(
  { sampleRate: 16_000, bufferLength: 1600, channelCount: 1 },
  (event) => { /* 100 ms chunks, forwarded to AssemblyAI over WS */ },
);

TTS side is 24 kHz LINEAR16 PCM into AudioBufferQueueSourceNode inside a new AudioContext({ sampleRate: 24_000 }). The 3x speedup ratio numerically matches 24/8, which is what made the route-rate-mismatch hypothesis tempting, but no source in my app actually requests 8 kHz.

A few additional details that may help narrow it:

• VPIO is NOT engaged on this 0.12.2 build. I historically patched setVoiceProcessingEnabled:YES into 0.11.7 for echo cancellation, but never ported that patch to 0.12.x and have now dropped it entirely (echo prevention happens at the app level by muting STT during TTS playback). So the 0.12.2 reproduction is on the default no-VPIO recorder path.
• Audio session: category = "playAndRecord", mode = "default" (not voiceChat), options = ["defaultToSpeaker", "allowBluetoothA2DP", "allowBluetoothHFP"].
• Reproduces deterministically on both physical iOS device and iOS Simulator. Since the Simulator routes through the host Mac's audio at the Mac's hardware rate (no bluetooth, no HFP), any 8 kHz path would have to come from inside the library, not from the OS route.

[mdydek]

ok, i was trying to get the grasp about the 24/8 issue, because i met only with sampleRate 0 when engine is invalid, or some values set by the user

[mdydek]

@marcospgp is there a possibility that you could put some logs in native files to make sure if sampleRates mismatch is really a thing?