No way to end audio session on iOS without disposing player.

[rarowston]

We are using this to play short sound clips (mostly as notifications). Because we are playing the same clips we have been caching the player after creating it once. This works fine on android which ends the audio session properly, however, iOS does not end the session and it appears that there is no way (other than disposing of the player) to end the audio session and allow other apps to resume playing audio.

We can work around this for now by always disposing on iOS, but it would be nice to share the behaviour.

I think the fix for this is to add an additional flag to AudioPlayerOptions.macios.cs to control this behaviour, and then to initialise the session on Play, and finish the session on Pause/Stop/Finish.

I have applied a possible fix for this into a local branch, but am unsure how to contribute to this project, so have attached a patch file below instead.
0001-Added-option-to-allow-for-audio-session-to-be-dynami.patch

[bijington]

@rarowston can you try changing the SessionLifetime property on AudioPlayerOptions?

[rarowston]

That is a fair idea, and I have set that to SessionLifetime.EndSessionAndNotifyOthers as it seems the most thorough.
Unfortunately, it seems to have no effect. From what I can gather, it also needs something to make the call to FinishSession where this value is actually checked, which (as best as I can tell) only happens on dispose.
So I think this is more of an 'and' situation where this needs to be set and the finish session needs to be called.

[bijington]

Ah yeah I see that it's only called in FinishSession now. Hmmm.

Are you able to open a PR with your changes in to make it easier to see what the changes are?

[rarowston]

I don't have permissions to push a branch to the repo (that or I am doing something wrong), I have included a patch file, but it is not quite as convenient. (Also I don't love the name of the config option I have set in this change).
If you grant me permissions I'd be happy to create a PR though.

[bijington]

Oh yeah the typical way to submit PRs is by forking the repository and then pushing those changes. That you already have permission to do as it would be your own copy of the repository. Let me see if I can find some documentation on it

Forking a repo https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo

Creating a branch https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository

Creating a PR https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork

[rarowston]

Thanks for that information. I have created a PR here with what I think is a viable fix for this (open to suggestions on config option name though). If we end up actually merging this I will also have to add some notes to the docs as well.