Enable OpenAL-Soft extensions for non-framework builds and add config for disabling HRTF #1620
Conversation
| @@ -2601,7 +2601,8 @@ def WriteConfigSettings(): | |||
| dtool_config["PYTHON_FRAMEWORK"] = 'Python' | |||
| dtool_config["PHAVE_MALLOC_H"] = 'UNDEF' | |||
| dtool_config["PHAVE_SYS_MALLOC_H"] = '1' | |||
| dtool_config["HAVE_OPENAL_FRAMEWORK"] = '1' | |||
| if not os.path.isdir(GetThirdpartyDir() + "openal"): | |||
| dtool_config["HAVE_OPENAL_FRAMEWORK"] = '1' | |||
There was a problem hiding this comment.
Hmm, this isn't perfect, but I can't see a better way right now
There was a problem hiding this comment.
I had the same thought. I couldn't find anything that specified whether openal was enabled specifically via the thirdparty directory. However, I think removing OpenAL Framework support entirely is going to be my next suggestion, so I didn't belabor the change too much.
There was a problem hiding this comment.
Fine - makepanda will be deprecated in favour of CMake shortly anyway.
| PRC_DESC("This determines whether OpenAL-Soft should activate HRTF in " | ||
| "certain hardware configurations. Set it to true to cause " | ||
| "OpenAL to automatically apply HRTF processing to all output " | ||
| "audio when headphones are used for playback.")); |
There was a problem hiding this comment.
Should we make this an openal-specific config variable?
There was a problem hiding this comment.
There are almost no config variables that specify that they are for openal by name, most of the config variables that do in fact only apply to openal just contain "audio" (I experienced this with audio-preload-threshold and I'm sure there are many others).
So my way making it an "openal-specific config" was just to place it along side the other ones. Let me know if there's more I should do for that.
|
Emscripten build failed... maybe we need a separate dtool_config.h flag for alext presence. |
|
Or, we need to just vendor alext.h, just like we do with glext.h... it's feature-gated at runtime anyway. |
Emscripten does actually support extensions, including the one I'm trying to use here ALC_SOFT_HRTF. Not sure how if they don't expose alext.h, since you kinda need the defines. Maybe they pack it into alc.h? I can experiment on my local. Otherwise yeah I can look into feature gating |
|
I am leaning towards investigating shipping our own alext.h. |
|
Poking around in the PR that added support for the ALC_HRTF_SOFT extension in Emscripten, specifically in the tests added for it, it seems they require you to specify the enum's value directly, which is not quite ideal for our case. That is to say, I agree that we could try to ship our own alext.h file for Emscripten builds to have access to the proper defines. I'll try to look into that soon, likely by looking at glext.h as you mentioned for an example. |
|
The missing |
|
alext.h landed in emscripten emscripten-core/emscripten#21857 so whenever the next version releases, if we bump to that, this PR should hopefully successfully build |
Issue description
There was no include for the
alext.hheader, meaning the engine could not use any OpenAL-Soft extensions. Additionally, HRTF was always enabled, meaning when OpenAL detected headphones as the output device, it would apply the default HRTF to the audio.Solution description
Added the
alext.hinclude for non-framework builds (the OpenAL framework does not include alext.h) and added a config variableaudio-want-hrtfto determine how theALC_SOFT_HRTFextension should be configured in the openal audio manager.Checklist
I have done my best to ensure that…
I've tested a wheel build of this branch using python3.9 on Windows, macOS, and Ubuntu 22.04
resolves #1613