Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OpenAL] Wrong exception type when binaries are missing #6515

Closed
mrhelmut opened this issue Oct 30, 2018 · 13 comments

Comments

@mrhelmut
Copy link
Contributor

commented Oct 30, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 30, 2018

I'm working on refactoring the entry points loading.

@Jjagg

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2018

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 mrhelmut changed the title [OpenAL] Wrong exception type when binaries is missing [OpenAL] Wrong exception type when binaries are missing Oct 30, 2018
@mrhelmut

This comment has been minimized.

Copy link
Contributor Author

commented Oct 30, 2018

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.

@cra0zy

This comment has been minimized.

Copy link
Member

commented Oct 30, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 30, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2018

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

@tomspilman

This comment has been minimized.

Copy link
Member

commented Oct 30, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 30, 2018

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

This comment has been minimized.

Copy link
Member

commented Oct 31, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 31, 2018

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

This comment has been minimized.

Copy link
Member

commented Oct 31, 2018

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?

@Jjagg Jjagg added the Audio label Dec 10, 2018
@mrhelmut

This comment has been minimized.

Copy link
Contributor Author

commented Jan 4, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 6, 2019

#6629 is up.

@Jjagg Jjagg closed this in #6629 Feb 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.