Critical Alert Sound Fades In Instead of Playing at Full Volume on iOS

Question

Created Aug ’24

Replies 2

Boosts 0

Participants 2

I’m currently developing an iOS app that includes critical alerts as part of our notification system. We’ve noticed an issue where, on some occasions, the critical alert sound fades in rather than playing immediately at full volume.

Behavior: When a critical alert is triggered, the notification sound sometimes fades in gradually, instead of starting at the desired volume level right away. This doesn’t happen every time, but it’s frequent enough to be concerning.

Has anyone else encountered this issue, or does anyone have insights into why this might be happening? We’re looking for advice on how to ensure the sound plays correctly every time a critical alert is triggered.

Answered by DTS Engineer in 802423022

Has anyone else encountered this issue, or does anyone have insights into why this might be happening?

This is almost certainly caused by the state of whatever other audio session happens to be active at the time. A few things I'd look at:

Test with different music and podcast apps, both when they're actively playing and when they're inactive (but still the now playing app).
Test with voip apps, particularly apps using CallKit (or PTT apps). CallKit is relevant here because it uses the same (unusually) high priority as critical alert does, which could trigger behaviors which wouldn't occur with other, lower priority sessions.
If your own app uses audio, make sure you look at when it activates/deactivates as well.

We’re looking for advice on how to ensure the sound plays correctly every time a critical alert is triggered.

The testing above may explain what's going on, but I'm not sure you'll really find a real "solution". I suspect the difference here caused by another audio session being active and the specific ducking behavior of that session, none of which you can really control. I'd probably try the "withAudioVolume" variant in UNNotificationSoundName, but I'm not confident it will make any difference. UNNotificationSoundName doesn't give you a lot to work with and there isn't any other alternative API.

The only other thing you could try here is altering the sound itself to mitigate the issue. For example, it's possible that including a small amount of silence a the start of the audio file (1-2s) would be enough to let the other audio finish ducking before you actually started playing any audio, making the two different cases sound identical.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

Sep ’24

Accepted Answer

Has anyone else encountered this issue, or does anyone have insights into why this might be happening?

This is almost certainly caused by the state of whatever other audio session happens to be active at the time. A few things I'd look at:

Test with different music and podcast apps, both when they're actively playing and when they're inactive (but still the now playing app).
Test with voip apps, particularly apps using CallKit (or PTT apps). CallKit is relevant here because it uses the same (unusually) high priority as critical alert does, which could trigger behaviors which wouldn't occur with other, lower priority sessions.
If your own app uses audio, make sure you look at when it activates/deactivates as well.

We’re looking for advice on how to ensure the sound plays correctly every time a critical alert is triggered.

The testing above may explain what's going on, but I'm not sure you'll really find a real "solution". I suspect the difference here caused by another audio session being active and the specific ducking behavior of that session, none of which you can really control. I'd probably try the "withAudioVolume" variant in UNNotificationSoundName, but I'm not confident it will make any difference. UNNotificationSoundName doesn't give you a lot to work with and there isn't any other alternative API.

The only other thing you could try here is altering the sound itself to mitigate the issue. For example, it's possible that including a small amount of silence a the start of the audio file (1-2s) would be enough to let the other audio finish ducking before you actually started playing any audio, making the two different cases sound identical.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

1

Answer 2

chabose_yolni OP

Oct ’24

Hi Kevin,

Thank you for your suggestions.

It seems reasonable to believe that other apps are holding the audio session (even though no sound is emitted), as this fade-in issue doesn't occur after rebooting.

We are already using withAudioVolume, and a 1-2 second blank could degrade our user experience since the alert is triggered by our Bluetooth device. So, this might not be a viable solution for us.

We still need to determine whether our app or other apps are holding the audio session, but your suggestion has been helpful in guiding us forward.

Thanks again.

0