feat: make it possible to play audio through the earpiece speaker

[Egbert-Jan]

This new functionality allows you to set the audioUsageType and audioContentType for Android, and the iosCategroy and iosCategoryMode for iOS with the updateOptions function. This makes it possible to force the audio to come through the earpiece speaker. This can for example be useful to play an audio message in a chat app. For this to work on Android I also made a pull request in KotlinAudio (doublesymmetry/KotlinAudio#105). I tried but could not get the RNTP example app to use the updated KotlinAudio repo while executing the publishToMavenLocal steps as shown in https://github.com/doublesymmetry/react-native-track-player/tree/main/example.

Example:
TrackPlayer.updateOptions({
iosCategory: IOSCategory.PlayAndRecord,
iosCategoryMode: IOSCategoryMode.VoiceChat,
androidAudioContentType: AndroidAudioContentType.Music,
androidAudioUsageType: AndroidAudioUsageType.VoiceCommunication
})

[Egbert-Jan]

Hello @jspizziri @dcvz, could you maybe take a look at this pull request? I think it would be a useful feature. If something is wrong with it I could fix it.

[dcvz]

Hey @Egbert-Jan we've been a bit busy, but I'll get to it as soon as I can.

[jspizziri]

@Egbert-Jan

I left some low-level feedback. All in all, it looks like it probably works, but I'd need to test it. However, before we go any further there's a high level design question that needs to be answered (and @dcvz will need to weigh in on it).

Should things like androidAudioUsageType and androidAudioContentType be pushed into the AndroidOptions object that we introduced in recent versions. So rather than doing:

TrackPlayer.updateOptions({
   androidAudioUsageType: ...,
   androidAudioContentType: ...,
   iosCategory: ...,
   iosCategoryMode: ...,
   iosCategoryOptions: ...,
   ...
})

You'd do:

TrackPlayer.updateOptions({
  android: {
    usageType: ...,
    contentType: ...,
  },
  ios: {
    category: ...,
    categoryMode: ...,
    categoryOptions: ...,
  },
   ...
})

Since we're introducing this into updateOptions for the first time, I think that is the right approach personally. However, it does cause an api consistency problem, where setupPlayer would be different than updateOptions (since these options already exist on setupPlayer and we don't want to introduce a breaking change).

What I propose is that we add android and ios config to setupPlayer in an identical manner and only allow the new properties to be set in that way. Then we can add a simple shim in the TS side, that maps legacy config of androidAudioContentType, etc. into the new android: AndroidOptions property. We then mark the top level properties as deprecated.

This would IMO, allow for a more organized, and consistent API between both updateOptions and setupPlayer.

Let me know your thoughts.

[Egbert-Jan]

Thanks I resolved the documentation and import issues. Have you also noticed I made a pull request here: doublesymmetry/KotlinAudio#105. Those changed are needed for these to work.

[jspizziri]

@watadarkstar & @Egbert-Jan , it seems that there is some overlap between your two PRs (#2259). Can the two of you evaluate and and if I'm not mistaken, collaborate?

[Egbert-Jan]

My pull request introduces the same functionality as #2259 for the iOS side. However it also adds the functionality to the Android side.

[tfkennedy777]

Just chiming in to say that I really appreciate the contributions on this issue, and I'm rooting for this to get merged! Would be super helpful to update these options on the fly after initialization.

[github-actions]

This PR is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This PR was closed because it has been stalled for 7 days with no activity.