Android: OpenAL fails to load due to missing SL_IID_ENGINE

[LordOfDragons]

Compile OpenAL Soft 1.22.2 for Android arm64-v8a min api level 26. Compiling works but trying to load the module using OpenAL fails with the following error:

II [Dragengine] [2024-12-25 23:51:57] - loading module openal 1.24
EE [Dragengine] [2024-12-25 23:51:57] dlerror: dlopen failed: cannot locate symbol "SL_IID_ENGINE" referenced by "/data/data/ch.dragondreams.delauncher/files/dragengine/lib/dragengine/modules/audio/openal/1.24/libaudopenal.so"....
EE [Dragengine] [2024-12-25 23:51:57] Library /data/user/0/ch.dragondreams.delauncher/files/dragengine/lib/dragengine/modules/audio/openal/1.24/libaudopenal.so could not be opened

I searched through the sources and found the reference here: https://github.com/apportable/openal-soft/blob/9658f0dc274eafa596dc55dd83f5decbf85f1497/jni/OpenAL/Alc/opensles.c#L427

This seems to be linked to OpenSLES. But as mentioned here it is deprecated: https://developer.android.com/ndk/guides/audio/opensl . To be on the safe side I also tried preloading the library but the error is the same:

System.loadLibrary("OpenSLES")

Could it be OpenAL is no work working on Android due to linking to a deprecated library? What could cause this symbol to me missing even when I ensure the library the symbol should be located in is loaded before hand?

[kcat]

I'm not sure where that code comes from, but it doesn't seem to be OpenAL Soft's OpenSL backend. It looks like a custom one, probably from before OpenAL Soft had its own OpenSL backend. Interestingly, the log shows it loading "openal 1.24", but the linked code base is very old, from over a decade ago. That code is also dynamically loading the SL_IID_ENGINE symbol, so it wouldn't result in a message like that.

It looks like it may actually be using a newer OpenAL Soft, which has a different OpenSL backend that doesn't dynamically load SLES symbols. I don't know why it would be failing though, libopenal.so should be linked to libOpenSLES.so for the symbols. Perhaps that version of Android moved the IID symbols to a separate lib that's not getting loaded, or it removed OpenSL support by removing the symbols from the public runtimes.

I found a couple other similar issues (different IIDs, though):
android/ndk#1733
mackron/miniaudio#183

The first blames a potentially faulty (possibly non-official) emulator image. The second didn't find a cause, though switched to dynamic run-time loading to fail gracefully if it's not found. I could, and I guess probably should, also do dynamic run-time loading, though you'll need an OpenAL build with Oboe or something enabled or else you'll get no audio.

[LordOfDragons]

You are right. No idea how I ended up with the wrong web links. In your code base of the matching version (which I'm using) the symbol is used in these two locations:

openal-soft/alc/backends/opensl.cpp

Line 330 in dc83d99

result = VCALL(mEngineObj,GetInterface)(SL_IID_ENGINE, &mEngine);

openal-soft/alc/backends/opensl.cpp

Line 700 in dc83d99

result = VCALL(mEngineObj,GetInterface)(SL_IID_ENGINE, &mEngine);

The problem happens on a real device when compiled using Android Studio 2024.2.1P3 using NDK 27.0.12077973

[LordOfDragons]

I've also tried now with the latest 1.24.1 release but the error is the same.

[kcat]

Commit e359dbf now will dynamically load libOpenSLES.so, so libopenal.so shouldn't fail if the IIDs are missing. The OpenSL backend won't work in that case, you'll simply get no devices rather than failing to load, so make sure Oboe is enabled.

[LordOfDragons]

Is the command line switch "-DALSOFT_REQUIRE_OBOE=ON" in that case?

EDIT: I checked the default build options and OBOE is by default enabled. So I assume I have to do nothing.

[kcat]

-DALSOFT_REQUIRE_OBOE=ON helps ensure Oboe gets enabled (cmake will fail if it doesn't, letting you know it's not). But depending on the system, you may need to do more to make it work. If it's not found automatically, you'll need to download the source for it and add the switch -DOBOE_SOURCE=/path/to/oboe, then it'll be built into libopenal.so.

[LordOfDragons]

I tried applying the patch from the commit to the 1.24.1 release but it fails. Looks like there are too many changes since then for the patch to work. I would prefer to apply the patch to a release version if possible.

[kcat]

It needs commit 8767fdd too, since commit e359dbf is fixing a couple things from it. Although it likely still won't work because logging is slightly different, and the WARN(...) lines probably won't compile (and will misbehave if it does compile and they get called).

I intend to make another release in the next few days, so it won't be too long before an updated release version.

[LordOfDragons]

That's fine with me. I'm not in a hurry right now with the Android stuff.

[kcat]

1.24.2 was released with this fix included.

[LordOfDragons]

Sorry. I didn't have time yet to yet it.

The missing SL_IID_ENGINE symbol is fixed but now I've got another problem:

dlerror: dlopen failed: cannot locate symbol "android_openal_setjavavm" referenced by "/data/data/ch.dragondreams.delauncher/files/dragengine/lib/dragengine/modules/audio/openal/1.25/libaudopenal.so"....

I have the suspicion that the "android_openal_setjavavm" has been required in older OpenAL versions but now it is no more present. What has to be done now to get openal properly receive the javavm pointer?

EDIT: I removed the function call and the library seems to load. Let's see if somewhere down the line a problem shows up.

[kcat]

I have the suspicion that the "android_openal_setjavavm" has been required in older OpenAL versions but now it is no more present. What has to be done now to get openal properly receive the javavm pointer?

That's not something from OpenAL Soft. There were times I would've liked to get the Java VM pointer to get access to information that wasn't provided through OpenSL, but I never got around to making such a function (and the little bit of code I wrote that would use the VM handle was always optional and never well-tested, and had been disabled for some time before getting removed). And with Oboe now, I don't really see a need for it.