Does Oboe rely on manual setVolume() or system configuration for Audio Ducking when integrated with AudioManager/AudioFocusRequest?

[changchaishi]

Hi everyone,

We are currently evaluating how Android's audio ducking behaves when using the Oboe library for low-latency audio playback, especially regarding its interoperability with Java/Kotlin AudioManager and AudioFocusRequest.

We would like to clarify a key question: If we successfully coordinate Oboe with Android's Audio Focus, do we still need to manually adjust setVolume() in our code when ducking occurs, or does the system configuration handle it automatically?

[MLuc24]

Neither, strictly — the part that's missing from the question is that Oboe has no volume control to call. There is no setVolume() on an Oboe stream. The only setVolume anywhere in this repo is in the OboeTester sample's Java UI, not in the C++ API.

So the options aren't "call setVolume vs. let the system do it". They're:

1. Apply gain yourself, by scaling the samples you write in your audio callback.
2. Do something other than duck — usually pause.

Oboe has no audio-focus integration either. It doesn't observe AudioManager, and nothing about focus reaches the stream. Focus stays entirely on the Java/Kotlin side, and whatever you decide there has to be communicated to your native audio code by you.

Worth looking at how Google's own Oboe sample handles exactly this. From samples/powerplay/.../AudioForegroundService.kt:

AudioManager.AUDIOFOCUS_LOSS,
AudioManager.AUDIOFOCUS_LOSS_TRANSIENT,
AudioManager.AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK -> {
    if (::player.isInitialized) {
        player.stopPlaying(player.currentSongIndex)
    }
}

It groups CAN_DUCK with the other two and stops playback. Its AudioFocusRequest doesn't call setWillPauseWhenDucked(...) at all, so it's on the default — and it still receives the callback and acts on it rather than leaving the stream to be handled for it.

That's a reasonable model to copy if pausing is acceptable for your use case, and it's the least code.

If you actually need to duck rather than pause, the shape is:

// audio thread
float gain = mGain.load(std::memory_order_relaxed);
for (int i = 0; i < numFrames * channelCount; i++) {
    buffer[i] *= gain;
}

with the Kotlin side setting that atomic to something like 0.2f on AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK and back to 1.0f on AUDIOFOCUS_GAIN. Ramp it over a few milliseconds rather than jumping — a step change in gain is an audible click, which is the usual reason a hand-rolled duck sounds worse than the system's.

One design note since you're evaluating: if you'd rather not implement ducking at all, setWillPauseWhenDucked(true) on your AudioFocusRequest states that intent explicitly, which is clearer than relying on default behaviour you'd then have to verify per Android version. Given that you have to do the volume work yourself either way, choosing deliberately between "I duck" and "I pause" is worth doing up front.