MonoGame
Drop OpenAL in favor of a better audio library
While OpenAL does exactly what MonoGame needs for the most part and is available on a wide range of systems, it is hardly compatible with XAudio.
XAudio is the API toward which MonoGame (and formerly XNA) has been design for. The problem is that XAudio isn't available outside of Windows and Xbox platforms.
OpenAL came as a workaround and has been used to implement an XAudio-like API on macOS, Linux, iOS/iPadOS, and Android.
However, OpenAL functions quite differently than XAudio and there are many features (like effects, or even applying a pitch/pan) which renders differently. This isn't just mathematical conversion issues. The effect API for instance, is so differently designed that it is plainly impossible to make an OpenAL effect to consistently sound exactly like its XAudio counterpart.
If we'd like to aim for accuracy and have all platforms sound the same, we should be looking into replacing OpenAL with a sound library that allows 1:1 XAudio mapping, and be available on macOS, Linux, iOS/iPadOS, and Android.
So far, the best candidate is FAudio, though it would need mobile ports.
Hi, Totally agree on this, FAudio works great and it's well integrated when using it with SDL2, where not possible maybe a per platform implementation can be added (Android OpenSLES etc), similar like this: https://github.com/FNA-XNA/FAudio/blob/master/src/FAudio_platform_win32.c
I don't understand the problem with openal. It works everywhere.
Why would you:
- use another library that just can play a song or sound effect, just like openal
- implement mobile versions of it while openal is already working now
what advantage will you have in the end over openal? I think there are only disadvantages because you need to mainatin all the mobile versions and you will never get the same compatibilty as openal.
I don't understand the problem with openal. It works everywhere.
Why would you:
* use another library that just can play a song or sound effect, just like openal * implement mobile versions of it while openal is already working nowwhat advantage will you have in the end over openal? I think there are only disadvantages because you need to mainatin all the mobile versions and you will never get the same compatibilty as openal.
I think the original issue stated it best, OpenAL is just too different than XAudio to work exactly the same, which is the goal.
Why should you want to make monogame work exactly as xaudio? Monogame should take his own path and now dwell on the past decisions XNA ever made.
Why should you want to make monogame work exactly as xaudio? Monogame should take his own path and now dwell on the past decisions XNA ever made.
What is wrong with XAudio? its quite a good audio API, and we still want to keep mostly compatible with XNA, as it makes porting old code very easy
I may have mislead you into this, but it has nothing to do with XNA. This is about platform consistency. I only mentioned XNA to retrace why XAudio was used in the first place and why it is the main target. MonoGame is specifically designed for XAudio, always has, always will be. OpenAL is a workaround. Currently a DesktopGL project using XACT effects doesn't, and can't sound exactly the same if played through a WindowsDX project. It already happened a few times that developers complain that their Windows game doesn't sound the same as their mobile game. I don't think that you would want that yourself.
As comfortable as it may sound to use OpenAL everywhere and calling it a day, that would basically be hiding issues under a blanket because this is assuming that something sounding wrong is correct. And the OpenAL implementation isn't even fully implemented because it just can't do some stuff (some effects will throw an exception).
FAudio has been specifically designed for that purpose: replacing OpenAL with a 1:1 copy of XAudio that works on all platforms so that stuff like XACT effects consistently sound the same everywhere.
Moreover, having multiple audio API makes maintaining and enhancing MonoGame more complicated and slower. Moving to only one API for all platforms is very much needed. This is about building a better future, and not stagnating because it feels comfortable.