Closing any SwiftUI Window Mutes Audio

Running into a major issue when we are supposed to have a public beta out tomorrow.
When any SwiftUI window, or volumetric window is dismissed, Unity Audio becomes muted.

This is because

-> applicationWillResignActive()
-> applicationDidEnterBackground()

Happens when any window is dismissed.
I’ve tried commenting out UnityUpdateMuteState and
Does anyone have a workaround?

@mtschoen You’re my only hope :stuck_out_tongue:

This seems to be an OS-level bug. We were seeing this as well a few versions ago when VR apps would initially launch with a window. Without any intervention from Unity, SwiftUI windows seem to “steal” the audio and make it sound like it’s coming from the window. And when you close the window, audio stops working. I wonder if maybe calling AudioSettings.Reset after closing the window will fix it, but I’m not sure…

I assume you’ve also tried the setIntendedSpatialAudioExperience workaround from this thread?

Yes, I have tried that as well (both with my way and your way), which fixes the audio coming from the swiftUI window but sadly, no luck as far as losing audio.

Also looking into

UnityUpdateMuteState(int mute);

yielded no results.

Sometimes when we reshow the immersive space audio can be heard again.

Yeah, I don’t think this is Unity muting the audio… for some reason the AVAudioSession just doesn’t work after you close the window.

Maybe you can try adding a slight delay between closing the window and restarting the immersive space? At this point your guess is as good as mine. This is something we’ll probably need Apple’s help for debugging. I would recommend trying to re-create the bug using a pure Swift Xcode project based on the visionOS app template for metal rendering. If you can see the same issue in that case, it’s definitely an Apple bug. You might be able to iterate more quickly on workarounds in that project where you have full source code.

Here’s a starting point that uses Swift for metal rendering and plays music similar to a Unity app with a 2D audio source. Good luck!

I think my next step in this case will be to try messing with shouldResume | Apple Developer Documentation

Yeah, I think you’re on the right track there. Clearly the OS thinks there’s a good reason to “interrupt” the session… just not sure why “interrupt” turns into “turn off forever” :upside_down_face:

Managed to capture the interruption in AVAudioSession.interruptionNotification

It sure would be nice if the reason VisionOS gives is something other than
AVAudioSessionInterruptionReasonKey = 0

Which according to VisionOS docs

`case `default``

The system interrupts this audio session when it activates another.

The real question is what can we do about it?? As far as I know, AudioSettings.Reset is the “nuclear option” on the Unity side to shut down and restart the audio system. If that’s not working, maybe we can find something that we can call in Swift/Objective C code to restart the audio session.