Monogame: [OpenAL] Wrong exception type when binaries are missing

[mrhelmut]

Hey there,

Even if none of the Audio namespace is used, MonoGame initialize the static OpenAL bindings and tries to load the library and its entry points, resulting in a EntryPointNotFoundException if the OpenAL binaries are missing.

This is an issue when using third party sound engines and not shipping the OpenAL binaries.

Please also note that this is broken: https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework/SDL/SDLGamePlatform.cs#L72

The DllNotFoundException is no more triggered because the entry points loading have changed and are now throwing EntryPointNotFoundException. And even if GetNativeLibrary() would throw the correct exception type, this code won't be triggered because it happens in the static initializer and no more within the OpenALSoundController constructor.

Related to #6107 and #4717

I think we should move forward with making the Audio namespace and its dependencies fully optional.

What version of MonoGame does the bug occur on:

• MonoGame 3.7

What operating system are you using:

• All

What MonoGame platform are you using:

• DesktopGL

[mrhelmut]

I'm working on refactoring the entry points loading.

[Jjagg]

I think we should move forward with making the Audio namespace and its dependencies fully optional.

Yes, I agree. People should easily be able to use a more elaborate third-party solution for audio if they need to.

[mrhelmut]

I've setup #6516 to repair OpenAL entry points, and I'm looking into making the audio namespace optional right now.

The main thing is to avoid calling SoundEffect.InitializeSoundEffect() within FrameworkDispatcher and skipping on the audio stuff in DoUpdate(). For this, we need something like a "NoAudio" parameter to pass to FrameworkDispatcher.

What would be the best strategy? Adding a property to Game so that it can be set before in the Game ctor? Or adding a Game() overload? Or something else?

cc @tomspilman for the design decision.

[harry-cpp]

This is actually a duplicate issue, there has been an issue about not crashing when openal is missing and instead just not playing sounds (also when audio device is missing).

[mrhelmut]

I don't know if it's a good use case. For example, we have a lot of players who were running into issues with OpenAL initialization, and having a non-slient stack trace sent to us with a crash log proved to be useful in helping those players overcoming their incompatibilities issues.

I expect a silent exception to make players wonder why they have no sound at all with developers being unable to figure out why.

My personal view on this issue is that it should be up to the developer to decide what to do upon a NoAudioHardwareException and that it shouldn't be fatal.

Anyway, there are 2 different questions/issues here:

• being able to disable the dependencies to oal_soft.dll if the audio namespace isn't used
• being able to proceed without sound support (and icing on the cake: being able for the dev to know that the initialization failed), which indeed a duplicate of #6107

[Jjagg]

Yeah, just silently failing in every case is not very dev-friendly. I'm in favor of offering the option to disable audio.

[tomspilman]

IMO we should throw NoAudioHardwareException and at the same time disable sound. This should let users catch and handle the exception if they like and continue or let it blow up.

[mrhelmut]

For now the problem is that the audio system is initialized during the Game constructor and that throwing the exception makes things fatal.

I'm trying to figure out a route, but I guess that we would have to add initialization checks to every audio calls?

[tomspilman]

I guess that we would have to add initialization checks to every audio calls?

Well... it would be needed in constructors for audio system types and any static audio functions.

It wouldn't be needed in non-static instance methods... as the constructor has to be called first.

So maybe less than we think.

[mrhelmut]

Design proposition:

• make audio initialization failures non fatal and silent;
• add a static method to SoundEffect to retrieve the possible exception that occurred silently during initialization (so that developers can act accordingly if need be);
• add a property to Game to have the possibility to not initialize the audio system at all (to avoid useless dependencies and conflicts with third party sound engine).

[tomspilman]

make audio initialization failures non fatal and silent;

I sort of agree with that.

I think if the developer opts in to this behavior... yes audio initialization failures can be non-fatal and silent.

But i think our default behavior should be to work like XNA and have audio initialization failures throw and exception that must be handled. This way the developer isn't surprised when his game has no audio for some players.... he instead gets crash reports he can diagnose.

But i suggest we fix our templates to maybe include this better initialization to alert new users of the feature.

add a static method to SoundEffect to retrieve the possible exception

I was thinking maybe instead we have a new optional initialization method. Like SoundEffect.Initialize() that one can call before the Game construtor or within the constructor or where ever that forces initialization and returns an exception to handle. It also disables the sound system so if you handle the exception and choose to continue you can do so.

If you don't call it the system will get initialized on first use which could be at any time and you get a fatal failure. Even then we could disable the sound system and let you continue without sound.

add a property to Game to have the possibility to not initialize the audio system at all

What would we do if then the game tries to call sound sound APIs? Should we crash or fail silently?

[mrhelmut]

I'm going to need audio systems to be optional very soon (because we'll be using FMOD), so you can expect a PR addressing all platforms in the coming days (based on Tom proposal).

Targeting to fix #6107 and #4717 as well.

[mrhelmut]

6629 is up.