AAudio callback stops permanently while stream remains Started on Huawei devices

[loserspiderman]

Android version(s):
Android 10

Android device(s):
Huawei Mate20
Huawei Nova8 Pro

Oboe version:
1.9.11

App name used for testing:
Custom TTS player using Oboe callback mode

Short description

On some Huawei devices, onAudioReady() eventually stops being called permanently after repeated playback start/stop operations using Oboe callback mode.

The stream still reports Started, and start() returns Result::OK, but the audio callback thread appears to be dead internally.

This issue only reproduces when using the AAudio backend. After forcing OpenSLES via:

builder.setAudioApi(oboe::AudioApi::OpenSLES);

the problem no longer reproduces.

The callback always returns oboe::DataCallbackResult::Continue. It never returns Stop.

Relevant logs:

AudioStreamLegacy: processCallbackCommon() no data because callback disabled
AudioTrack: processAudioBuffer(): EVENT_MORE_DATA requested xxx bytes but callback returned -1 bytes

Steps to reproduce

1. Open an output callback stream using Oboe
2. Start playback
3. Stop playback
4. Start playback again
5. Repeat start/stop multiple times

Eventually:

• start() still returns Result::OK
• stream state becomes Started
• but onAudioReady() is never called again

The stream uses callback mode:

builder.setDataCallback(this);

The callback implementation always returns:

return oboe::DataCallbackResult::Continue;

Simplified stop logic:

_audio_stream->stop();

No pause/flush is involved in the final reproduction case.

Expected behavior

After calling start(), onAudioReady() should continue to be invoked normally.

If the callback pipeline becomes invalid internally, the application should receive an error callback or disconnected state notification.

Actual behavior

start() succeeds and the stream state is Started, but onAudioReady() stops being called permanently.

No error callback is triggered.

From the application perspective, the stream appears alive, but audio playback is effectively dead.

Device

The issue has been reproduced on:

• Huawei Mate20
• Huawei Nova8 Pro

The issue has not been reproduced on other non-Huawei Android devices so far.

Any additional context

Additional observations:

• Java AudioTrack write mode does not reproduce the issue.

• Logs show AudioStreamLegacy, suggesting the stream is using the AAudio legacy AudioTrack path instead of MMAP.

• The callback frequency is stable before the issue occurs.

• The issue still reproduces after ensuring:

  • callback never returns Stop
  • no pause/flush is used
  • audio buffer is fully filled with valid PCM or silence

• After forcing OpenSLES instead of AAudio, the issue disappears completely.

Questions:

1. Is this a known limitation or issue in the AAudio legacy callback path on some devices?
2. Is there a recommended way to detect this callback-dead state?
3. Is recreating the stream the expected recovery strategy in this situation?