AVAudioSession still initialized even if Unity Audio is disabled

If you disable Unity Audio in an iOS project, and build the Xcode solution, notice how the - (void)startUnity: method still sets it active, retrieves Mute State, and Video Player still activates it.

It might be valid in some cases (as the Video Player requests it), but it means Unity initializes the OS Audio with default values before any other piece of code can be ran. So if you disabled Unity Audio, and actually wants to play audio as Ambient (or not at all), the device will mute background music on splash screen, making it impossible.

It’s obviously possible by overriding the App Controller class, but even there it’s inconvenient as the operations are in a sea of other operations.

Expected: When Unity Audio is disabled, it shouldn’t start the Audio processes for the system.
Expected (2): It should be easy to override this functionality, so you can override UnitySetActiveAudioSession() once in a derived App Controller.

Running into the same issue. When Unity Audio is disable it should not mess with
AVAudioSession because this in turn messes with FMOD. Temporary workaround for me was to disable

AVAudioSession* audioSession = [AVAudioSession sharedInstance];
    [audioSession setActive: (UnityShouldActivateAVAudioSession() == 1) error: nil];
    [audioSession addObserver: self forKeyPath: @"outputVolume" options: 0 context: nil];
    UnityUpdateMuteState([audioSession outputVolume] < 0.01f ? 1 : 0);

in UnityAppController.mm so that FMOD can start up without issues.

I’m experiencing the same issue with Unity 2020.3.18f and Wwise in iOS project.
Wwise can’t properly initialize itself at app launch with error “Hardware audio subsystem stopped responding. Silent mode is enabled”, but restores on app switch or just after some delay.

In Unity 2019 AVAudioSession was always active.
Classes/UnityAppController.mm

    AVAudioSession* audioSession = [AVAudioSession sharedInstance];
    [audioSession setActive: YES error: nil];
    [audioSession addObserver: self forKeyPath: @"outputVolume" options: 0 context: nil];
    UnityUpdateMuteState([audioSession outputVolume] < 0.01f ? 1 : 0);

So I just reverted to setActive: YES (wrote simple postprocessor) and everything is working as expected.

To understand audio session in iOS there is a good article in Wwise docs.

And it seems to be fixed in 2020.3.19f

    AVAudioSession* audioSession = [AVAudioSession sharedInstance];
    [audioSession setCategory: AVAudioSessionCategoryAmbient error: nil];
    if (UnityIsAudioManagerAvailableAndEnabled())
    {
        if (UnityShouldPrepareForIOSRecording())
        {
            [audioSession setCategory: AVAudioSessionCategoryPlayAndRecord error: nil];
        }
        else if (UnityShouldMuteOtherAudioSources())
        {
            [audioSession setCategory: AVAudioSessionCategorySoloAmbient error: nil];
        }
    }

    [audioSession setActive: YES error: nil];
    [audioSession addObserver: self forKeyPath: @"outputVolume" options: 0 context: nil];
    UnityUpdateMuteState([audioSession outputVolume] < 0.01f ? 1 : 0);