rename alwaysPauseOnInterruption OR improve audio category and interruption handling (ducking)

[puckey]

As reported in the Discord, I was confused by the alwaysPauseOnInterruption setting. I expected it to pause the music on every interruption.. but when I set it, it does not seem to have any effect.. After checking the docs, I found it controls whether the remote-duck event is emitted.. in which case, it is up to me to either pause or stop the audio depending on the parameters in the event object..

some proposals from chat:

• triggerRemoteDuck
• listenRemoteDuck
• emitRemoteDuck
• activateRemoteDuckEvent
• enableRemoteDuckTriggering
• enableRemoteDuck
• willRemoteDuck

some aspects the name should cover:

• without setting it, you are expecting the system to take care of it for you
• it involved both pausing and stopping
• when set, it will start emitting remote-duck events, which you need to subscribe to and handle

I would suggest emitDuckEvents or manualDucking.

[curiousdustin]

Along with this, we should clarify if it is required to listen and react to remote-duck events in order to make an application at minimum play nice with other audio apps.

Without using any duck related settings or code, what is the expected behavior of RNTP audio when other apps try to play audio?

[Guichaguri]

I've been thinking about changing the behavior on Android to match iOS, I don't see any use-case where you want to do something other than pausing or lowering the volume, but I'd love to know whether there is one.

I should also point that remote-duck doesn't sound intuitive either, maybe we should also rename it to remote-interruption?

[Guichaguri]

I'm pretty sure what controls ducking or pausing on iOS is the iosCategoryOptions option, which lets you set the mixWithOthers and duckOthers properties. Should we unify those two options for both platforms?

[curiousdustin]

On iOS, iosCategory, iosCategoryOptions, and iosCategoryMode can also affect the default behavior that controlled by iOS. For instance, some mode pause for other audio, while other automatically lower the volume.

Are there similar settings on Android that we should expose through the API?

[puckey]

The android audio-focus guide includes a relevant example: an app with spoken word audio might want to pause playback instead of lowering volume during an interruption: https://developer.android.com/guide/topics/media-apps/audio-focus#automatic-ducking

[Guichaguri]

Yeah, and that's it. Android lets you control the behavior, there's in fact a setting like the category one, but it's not used for that. We can also add those categories on Android and hardcode the ducking behavior.

[puckey]

Yes agreed, that would be a really good solution.

[Guichaguri]

Let's find a common ground for both platforms. On Android, there are:

• CONTENT_TYPE_MOVIE: I don't think this would fit for this module as we don't have video
• CONTENT_TYPE_MUSIC
• CONTENT_TYPE_SONIFICATION: Sound effects, I don't know if this would fit either
• CONTENT_TYPE_SPEECH: Useful for podcasts
• CONTENT_TYPE_UNKNOWN

Besides the content type, we also have the usage type:

• USAGE_ALARM: Sound effects such as an alarm
• USAGE_ASSISTANCE_ACCESSIBILITY: Accessibility-based audio such as screen readers
• USAGE_ASSISTANCE_NAVIGATION_GUIDANCE: Driving/navigation direction
• USAGE_ASSISTANCE_SONIFICATION: Sound effects
• USAGE_ASSISTANT
• USAGE_GAME
• USAGE_MEDIA
• USAGE_NOTIFICATION
• USAGE_NOTIFICATION_COMMUNICATION_DELAYED: Non immediate notification audio for communication (e.g. email)
• USAGE_NOTIFICATION_COMMUNICATION_INSTANT: Immediate notification audio for communication (e.g. whatsapp)
• USAGE_NOTIFICATION_COMMUNICATION_REQUEST: Notification audio for entering a communication call
• USAGE_NOTIFICATION_EVENT: Notification audio for reminders
• USAGE_NOTIFICATION_RINGTONE
• USAGE_VOICE_COMMUNICATION
• USAGE_VOICE_COMMUNICATION_SIGNALLING: busy voice communication sound
• USAGE_UNKNOWN

I don't think any of those usages fit other than the USAGE_MEDIA and USAGE_UNKNOWN

---

On iOS, according to the docs, there is:

• default
• gameChat
• measurement
• moviePlayback
• spokenAudio
• videoChat
• videoRecording
• voiceChat
• voicePrompt

I think only the default and spokenAudio modes fit.

There is also the category:

• ambient: For audio that can be turned off
• multiRoute: For multiple audio instances being played at the same time
• playAndRecord: e.g. VOIP
• playback: Only for playing audio
• record: Only for recording audio
• soloAmbient: The default category

---

I think we can map them as such:

• Music
  • Android Content Type: CONTENT_TYPE_MUSIC
  • Android Usage: USAGE_MEDIA
  • iOS Mode: default
  • iOS Category: playback
  • Automatically duck on interruption
• Speech
  • Android Content Type: CONTENT_TYPE_SPEECH
  • Android Usage: USAGE_MEDIA
  • iOS Mode: spokenAudio
  • iOS Category: playback
  • Automatically pause on interruption
• Unknown
  • Android Content Type: CONTENT_TYPE_UNKNOWN
  • Android Usage: USAGE_UNKNOWN
  • iOS Mode: default
  • iOS Category: soloAmbient
  • Automatically pause on interruption

Unset should fall back to music instead of unknown for backwards compatibility. With that option, we can remove alwaysPauseOnInterruption, iosCategory, iosCategoryMode and maybe even iosCategoryOptions. What do you think?

[curiousdustin]

I think this would be a great improvement.

Also, at least on iOS, we will need to add a bit of extra logic to completely automatically duck/pause. For instance, in my production app, I am using spokenAudio/playback, and everything works automatically except that I have to manually resume by responding to remote-duck.

I think the goal is that developers don't have to implement any logic for remote-duck, unless they want to do something out of the ordinary, or update UI or something, correct?

I'm not sure we should remove iosCategoryOptions.

Do you see this as a breaking change, v2 feature, @Guichaguri ?

[Guichaguri]

I think we should still keep remote-duck for resuming the track. There are a few cases where resuming is not desirable. The only difference is that I'd make Android behave just like iOS.

[bradfloodx]

@Guichaguri is this still relevant? Thank you :)

[jspizziri]

Closing this due to inactivity. If someone finds this is still an issue in v2 let us know and we'll reopen it!