[expo-av][iOS] Duck / unduck is not working properly on iOS

[andrecrimb]

Minimal reproducible example

https://github.com/andrecrimb/expo-av-duck-unduck-issue.git

What platform(s) does this occur on?

iOS

Did you reproduce this issue in a development build?

Yes

Summary

Problem:

On iOS, with the audio mode setting interruptionModeIOS: InterruptionModeIOS.DuckOthers, the volume of ongoing music is reduced when a new sound is played. However, once the new sound is unloaded, the volume of the ongoing music does not return to its original level. This issue does not occur on Android, where the volume returns to normal as expected.

References:

1. This issue was previously mentioned in [expo-av] Ducked Audio doesn't stop being ducked. #19042, but it was closed without a solution.
2. The problem seems to have been introduced in [expo-av][iOS] - Fix AVAudioSession deactivation #16578, which addressed the frame drops issue.

Workaround Attempt:

I tried bypassing the use of interruptionModeIOS by implementing a custom solution for handling ducking/unducking on iOS, following this example. This workaround did not result in massive frame drops.

Preview - Turn on the video sound 🔉

Android - ✅ Works properly	iOS - ❌ Doesn't work properly
example-android-no-issue.mp4	example-ios-with-issue.MP4

Steps to Reproduce:

1. Set the audio mode with interruptionModeIOS: InterruptionModeIOS.DuckOthers.
2. Use some music player to play some music.
3. Press the Play sound button via app, causing the ongoing music volume to duck.
4. Press the Unload sound button.
5. Observe that on iOS the ongoing music volume does not return to its original level.

Expected Behavior:

After unloading the new sound, the volume of the ongoing music should return to its original level.

Actual Behavior:

The volume of the ongoing music remains reduced.

Environment

  expo-env-info 1.2.0 environment info:
    System:
      OS: macOS 14.3.1
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 18.16.0 - ~/.nvm/versions/node/v18.16.0/bin/node
      Yarn: 1.22.19 - ~/.nvm/versions/node/v18.16.0/bin/yarn
      npm: 9.5.1 - ~/.nvm/versions/node/v18.16.0/bin/npm
      Watchman: 2023.02.20.00 - /usr/local/bin/watchman
    Managers:
      CocoaPods: 1.15.2 - /Users/....my path/.rvm/gems/ruby-2.7.5/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 23.4, iOS 17.4, macOS 14.4, tvOS 17.4, visionOS 1.1, watchOS 10.4
      Android SDK:
        API Levels: 28, 30, 31, 33, 34
        Build Tools: 30.0.2, 30.0.3, 31.0.0, 32.0.0, 32.1.0, 33.0.1, 34.0.0
        System Images: android-29 | Google APIs ARM 64 v8a, android-30 | Google APIs ARM 64 v8a, android-30 | Google APIs Intel x86_64 Atom, android-30 | Google Play ARM 64 v8a, android-31 | Intel x86 Atom_64, android-31 | Google APIs ARM 64 v8a, android-31 | Google APIs Intel x86 Atom_64, android-31 | Google Play Intel x86 Atom_64, android-32 | Google Play ARM 64 v8a, android-32 | Google Play Intel x86 Atom_64, android-33 | Google Play ARM 64 v8a, android-34 | Google Play ARM 64 v8a
    IDEs:
      Android Studio: 2022.3 AI-223.8836.35.2231.10406996
      Xcode: 15.3/15E204a - /usr/bin/xcodebuild
    npmPackages:
      expo: ~51.0.8 => 51.0.8 
      react: 18.2.0 => 18.2.0 
      react-native: 0.74.1 => 0.74.1 
    Expo Workflow: managed

Expo Doctor Diagnostics

✔ Check Expo config for common issues
✔ Check package.json for common issues
✔ Check native tooling versions
✔ Check dependencies for packages that should not be installed directly
✔ Check for common project setup issues
✔ Check for issues with metro config
✔ Check npm/ yarn versions
✔ Check Expo config (app.json/ app.config.js) schema
✔ Check that packages match versions required by installed Expo SDK
✔ Check for legacy global CLI installed locally
✔ Check that native modules do not use incompatible support packages
✔ Check that native modules use compatible support package versions for installed Expo SDK

Didn't find any issues with the project!

[mnightingale]

Just my two cents, I agree #16578 has caused this regression which it seems I did worry about at the time.

It's been years since I've done anything with the expo sdk or objective-c, but I'd suggest at least the session setActive call and potentially all the session calls or the whole _updateSessionConfiguration method should be made async and queued with dispatch_async.
I'm not sure how you'd refactor the module since it expects several methods to return NSError, presumably there is a way to notify the js of an error that wasn't directly in response to js call.

For example something like this should resolve ducking and not cause framedrops, but I haven't made any attempt to handle potential errors and I'm not sure the EX_* stuff is correct.

if (!shouldBeActive && _sessionIsActive) {
  EX_WEAKIFY(self);
  dispatch_async(dispatch_get_main_queue(), ^{
    EX_ENSURE_STRONGIFY(self);
    
    NSError *error;
    [session setActive:NO error:&error];
    if (!error) {
      self->_sessionIsActive = NO;
    }
    // Does not handle the error
  });
}

[arsotech]

Experiencing the same issue

[Sergiohcp]

Was someone able to fix this problem?

[kibolho]

Same!