negative interaction with audio_session

[lukepighetti]

ryanheise/audio_session#138

[alnitak]

Hey @lukepighetti,

I read ryanheise reply. Unfortunately, I don't have a Mac to try. What I can say is that loadAsset() does nothing else than read using rootbundle or give the file directly to the native if it is already cached.

In the flutter_soloud version you are using, an Isolate is used to perform the native call. This could be the only reason that come to my mind that could cause something out of the ordinary. The main branch got rid of the Isolate and maybe worth to try it. It's not yet been published, so you should link this repo in your pubspec.yaml like:

  flutter_soloud:
    git:
      url: https://github.com/alnitak/flutter_soloud.git
      # Add this if you want to try with the incoming web support.
      # path: web

Also, have you tried to load the asset before calling _session.setActive(true)?

[sbauly]

I’m also experiencing issues with SoLoud’s interaction with audio_session, although I haven’t experienced the same issue as @lukepighetti.

It seems that the way SoLoud is handling interruptions internally could be interfering with attempts to use audio_session.

I made a quick example app that highlights the issue on iOS. The app uses one AudioSession instance with the exact same implementation for just_audio and SoLoud.

RPReplay_Final1721036954.mov

You can see from the video:

1. When an interruption occurs in SoLoud, the audio will not resume. You have to call SoLoud.instance.init() again and reload the asset before you can call play() successfully. This is not ideal, as it adds a lot of code and also means that the audio must be restarted again from the very beginning of the track after an interruption, losing the position of the audio that was being played.

2. When an interruption occurs in just_audio, the session correctly loses and regains focus as you would expect, maintaining the position of the audio.

Ideally, SoLoud would leave all interruption logic to be handled in audio_session, which would allow for one centralized place for session logic and handling of more complex scenarios. I’ve been using the main branch as suggested by @alnitak, and also tried using a local fork of SoLoud, commenting out some of the interruption logic I could find like ma_device_notification_type_interruption_began - but I haven’t been able to find a fix yet. This only appears to be a problem on iOS.

[alnitak]

Hi @sbauly, thank you very much for your findings and your time.

This seems related to #86. When I tried to look at this, the only notifications I saw were the start and stop. These notifications are listened here if you are curious.

I'll try to look at this issue again even if I cannot try it on iOS. Do you mind sharing your "quick example"?
Thanks again.

[sbauly]

Thanks for your speedy reply @alnitak!

Regarding #86 I’ve found that mixing sounds is possible by using the audio_session package and setting AVAudioSessionCategoryOptions.mixWithOthers when you configure the audio session, I’ve been able to accomplish that successfully with SoLoud.

The problem I’ve found is pausing/resuming SoLoud when an interruption event occurs. Android allows multiple audio sessions so it isn’t causing problems there, but on iOS I suspect that some of the AVAudioSession code in flutter_soloud is conflicting with audio_session in some way (possibly from miniaudio.h?). Thanks for your suggestion - I tried commenting out the start and stop methods but haven’t managed to find success yet, other than re-initializing SoLoud after each interruption as a temporary workaround.

I have published the example app here, hopefully it can be helpful

[ABespolov]

you just need to set AVAudioSessionCategoryAmbient

 if (![pAudioSession setCategory:AVAudioSessionCategoryAmbient withOptions:options error:nil]) {
                return MA_INVALID_OPERATION;  /* Failed to set session category to Ambient. */
         }

        if (!pConfig->coreaudio.noAudioSessionActivate) {
            if (![pAudioSession setActive:true error:nil]) {
                ma_log_postf(ma_context_get_log(pContext), MA_LOG_LEVEL_ERROR, "Failed to activate audio session.");
                return MA_FAILED_TO_INIT_BACKEND;
            }
        }

[sbauly]

Hi @ABespolov , thanks for the suggestion. Could you elaborate on this issue?

I've tried setting the avAudioSessionCategory to AVAudioSessionCategory.ambient in my AudioSessionConfiguration, but it has still had no effect on the issue of SoLoud being unable to resume playback after an interruption.

The only solution I have found so far is to re-initialize SoLoud after each interruption event. In the example app I published, the just_audio and SoLoud implementations use the exact same audio_session configuration, yet only SoLoud has an issue, which has lead me to believe this is a SoLoud specific issue, rather than a problem with the audio_session configuration I have been using.