MonoGame icon indicating copy to clipboard operation
MonoGame copied to clipboard

OpenAL/GL does not react to audio source changes

Open SimonDarksideJ opened this issue 8 months ago • 4 comments

Prerequisites

  • [x] I have verified this issue is present in the develop branch
  • [x] I have searched open and closed issues to ensure it has not already been reported.

MonoGame Version

3.8.2.2042-develop

Which MonoGame platform are you using?

MonoGame Cross-Platform Desktop Application (mgdesktopgl)

Operating System

Windows

Description

Currently, if the audio source changes whilst a game is running, the MonoGame audio system does not react and change the playing audio source.

Steps to Reproduce

  1. My sound was to my Microphone (because why not) as I forgot to turn on my speaker
  2. I stated the game
  3. I then activated my speaker which changed the audio source
  4. I could hear no audio in game

Minimal Example Repo

No response

Expected Behavior

Audio should change source or have an event that can be captured in game to refresh audio to the new source

Resulting Behavior

No sound in new speaker when audio selection changed

DX/Android/iOS are unaffected. Only affects DesktopGL builds

Files

No response

SimonDarksideJ avatar Apr 04 '25 14:04 SimonDarksideJ

Unfortunately OpenAL has no capability to detect that.

That's another reason to move away from it.

ThomasFOG avatar Apr 07 '25 07:04 ThomasFOG

OpenAL might not, but MonoGame uses OpenALSoft which is a software implementation of the original. That in turn makes calls to the platform's backend system, which for Windows should be WASAPI. My understanding is this is how modern XAudio2/DirectSound work as well where they are essentially virtual reimplementations which are then fed to WASAPI.

Image

Seems the OpenALSoft extensions are available in MonoGame.Library.OpenAL for this functionality, so it's just not implemented on MonoGame.Framework side. I guess that does raise the question that, with OpenALSoft getting regular commits/updates, how many issues related to OpenALSoft actually need fixing with MonoGame's implementation now. Still think switching to FAudio is probably best, although I haven't looked into it fully myself.

squarebananas avatar Apr 07 '25 16:04 squarebananas

Good to know! Thanks for pointing this out, I didn't know that OpenAL-Soft has its own set of extensions but that makes sense.

If anyone wants to tackle this problem, it's indeed welcome, especially considering that DesktopGL might never be upgraded to FAudio since the focus is on the D3D12/Vulkan target with the intent to deprecate DesktopGL. So we're likely better off fixing what we can on the OpenAL implementation. (Still, if anyone wants to submit a PR migrating to FAudio for DesktopGL, that's very much welcome.)

Still, there are a few issues that will be hardly fixable, or just impossible to fix. For instance, effects like reverb don't match the XAudio implementation, which makes XNA games to sound different on DesktopGL. And it seems that OpenAL uses a totally different paradigm to handle reverb which makes 1:1 replication impossible. That's basically the key problem with OpenAL, no matter the effort, it'll never sound the same as WindowsDX/XNA (unless we do some sort of manual software processing of the reverb before sending it to OpenAL, but that seems more effort than switching to FAudio).

ThomasFOG avatar Apr 09 '25 08:04 ThomasFOG