High CPU usage and crackling audio on iOS 26 simulator when playing audio

[radiodario]

Description

Hi there, we're using RN audio api 0.8.2 in our project and after updating to expo 53 + iOS 26 we are experiencing crackling audio during playback of base64 encoded mp3

On the Xcode console, we can see a large number of these logs:

HALC_ProxyIOContext.cpp:1623 HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload

We have a singleton audio context that we start up at the app boot lifecycle. Playback seems fine the first time we play audio, but any succeeding playback sessions (using the same context) are crackly

crackle.mp4

Thank you RNAA team!

Steps to reproduce

1. Install expo 53 and RNAA 0.8.2 and build and run the app on Xcode 26 (new architecture off)
2. Play mp3 audio buffers
3. CPU usage is high (140%) and js thread very busy

Snack or a link to a repository

MindmaxLabs/mobile

React Native Audio API version

0.8.2

React Native version

0.79.6

Platforms

iOS

JavaScript runtime

Hermes

Workflow

Expo Dev Client

Architecture

Paper (Old Architecture)

Build type

Debug app & dev bundle

Device

iOS simulator

Device model

all models

Acknowledgements

Yes

[michalsek]

Thanks, we are looking into it! 🙂

[jsonxr]

I get audio crackling on my macos just from running the simulator not even running a reactnative app. Are you sure it's not just an apple bug?

[michalsek]

I don't have yet a full picture (and if it is an issue on apple side, I might never get it 😃),

but the issue is caused by deactivating the audio session after one playback session, and activating it again on next one (AudioManager.setAudioSessionActivity).

Since it is working correctly on normal devices, it might be an issue with the simulator itself 🤞

An quick workaround might be to not call the session deactivation, f.e. by using expo Device.isDevice

Regarding the proc usage spike, it probably is unrelated, I would check how it performs with release scheme (so "production" react-native build), as debug/dev related code of react-native&co might be the main culprit here 🙂

[radiodario]

Thanks for looking into it, I will add the sim check on the session activity for the moment, and do some performance monitoring on device! Thanks!