Session Management

Flutter Sound 6.x, 7.x and 8.x has several verbs and parameters to try to handle the Audio Session.

Unfortunately, iOS can have only one session per App. This has two consequences : 1. Flutter Sound has compatibility issues with other plugins (like Just Audio) 2. There are some strange effects on iOS when Flutter Sound tries to manage several Flutter Sound Players or Recorders

Because of the iOS limitations, the only correct solution is to manage the Audio Sessions inside a central library. (Just)Audio Session is one possible central plugin doing that.

But there is a problem : If we remove from Flutter Sound everything about session management, then the startPlayer() verb will not be able to play on the speaker if the App did not use (Just)Audio Session before, for setting the correct flags inside the iOS session

This means that almost all App will have to depend on (Just)Audio Session plugin and will have to add some code to call it.

We must decide : - (1) - We remove completely the Audio Session management from Flutter Sound - (2) - We keep the current API for Flutter Sound 9.0

---

We must vote. My own vote is (2) : keep the current code.

This choice is because I am not 100% sure that everybody will not have some backward compatibility. Actually we have no Problem Report on this subject. So better not to change anything

***

@Larpoux

I have read your discussion about session management. My vote is for (1) - completely remove Session Management from Just Sound.

Here are my reasons.

You have correctly identified that under certain platforms (iOS for instance) there can only ever be one Audio Session per app which means when you mix and match plugins that attempt to maintain their OWN audio sessions internally - you will get issues when your code switches between functionality that uses a mixture of audio plugins.

I believe firmly in constructing apps that are built upon a firm SBA (Service based Architecture). This allows for seamlessly integration of disparate services and plugins. Single chain of responsibility should be adhered to at all times - if there isn’t anything else out there in the public domain which is good enough, tried and tested then sure - we need to think about rolling our own service to handle Audio Session management - but the Audio Session management from the ‘Audio Session’ plugging is simple to implement and setup and caters for every conceivable setting for both iOS and Android - it would be a wise choice to allow the users to decide which Audio Session API they wish to use.

Removing Audio Session management from Flutter Sound will inevitably lead to some breaking changes (As you have pointed out - the user may not hear any sound if an invocation to AudioSessionConfiguration is not made) - however, I dont see this as a hurdle, there are always breaking changes in Flutter and/or Cloud Firestore during any major release. We can easily document what needs to be done when we release Flutter Sound 9.0.

Removing Session Management completely from Flutter Sound further reduces the complexity of managing this within the plugin and offloads this to other plugins that will handle this well (Just Audio Session being one such plugin). We could also (but I dont recommend at this stage) strip out the functionality of session management from Flutter Sound into a new Plugin so that other users can have choices as to which Audio Session Plugin they want to use.

To summarise, I feel new life needs to be brought back into Flutter Sound. The plugin needs to be streamlined. It needs to be lightweight. We need to remove unnecessary complexity and completely adhere to Single Chain of Responsibility. We need to step back from previous architectural choices of trying to make Flutter Sound ‘All things to all people’ and just concentrate on what makes Flutter Sound good. We need to build on Flutter Sounds strengths not its weaknesses. We are making some breaking changes anyway to Flutter Sound 9.0 (No more Lite/Full, removing background Audio, no more FFMPEG etc ) - by removing Audio Session from Flutter Sound is a benefit and the correct design decision since it will no longer set in stone the Audio Session architecture but will easily allow users the CHOICE of which Audio Session architecture THEY WISH to use.

Finally - just to show you how easy it is to set up Audio Session management :

This is all that we need :

Future<void> _configure() async {

final session = await AudioSession.instance; if (DeviceHelper.isiOS) {

await session.configure(AudioSessionConfiguration.speech());

} else {

session.configure(AudioSessionConfiguration(

avAudioSessionCategory: AVAudioSessionCategory.playback, avAudioSessionCategoryOptions:

AVAudioSessionCategoryOptions.interruptSpokenAudioAndMixWithOthers,

avAudioSessionMode: AVAudioSessionMode.spokenAudio, avAudioSessionRouteSharingPolicy:

AVAudioSessionRouteSharingPolicy.defaultPolicy,

avAudioSessionSetActiveOptions:

AVAudioSessionSetActiveOptions.notifyOthersOnDeactivation,

androidAudioAttributes: const AndroidAudioAttributes(

contentType: AndroidAudioContentType.music, flags: AndroidAudioFlags.none, usage: AndroidAudioUsage.notification,

), androidAudioFocusGainType:

AndroidAudioFocusGainType.gainTransientMayDuck,

androidWillPauseWhenDucked: true,

));

}

}