| Summary: | JOAL OpenALSoft fallback option missing or not working properly | ||
|---|---|---|---|
| Product: | [JogAmp] Joal | Reporter: | Julien Gouesse <gouessej> |
| Component: | core | Assignee: | Sven Gothel <sgothel> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | gouessej, xerxes |
| Priority: | --- | ||
| Version: | 1.0 | ||
| Hardware: | pc_all | ||
| OS: | all | ||
| Type: | --- | SCM Refs: |
gluegen abbe6ce0973fbd82971ace1866515beefcc41817
|
| Workaround: | --- | ||
| Attachments: | joal-jogamp.debug.log | ||
Please help narrowing this issue by running the JOAL manual tests on your system with debugging enabled and attach the log: java -cp gluegen-rt.jar:joal.jar:joal-test.jar -Djogamp.debug.NativeLibrary=true -Djoal.debug=true com.jogamp.openal.test.manual.OpenALTest Created attachment 377 [details]
joal-jogamp.debug.log
This is a fine bug in... gluegen.
Testcase:
java -Djogamp.debug=true -cp gluegen-rt.jar:joal.jar:joal-test.jar com.jogamp.openal.test.manual.OpenALTest
Attached debug log:
The joal-natives-linux-armv6.jar is picked up:
The libopenal.so is extracted in a temp dir
Unfortunally NativeLibrary.open() never tries to load the extracted lib inside the temp dir.. :/
JarUtil: JarEntry : isNativeLib true, isClassFile false, isDir false, isRootEntry true
JarUtil: EXTRACT[2]: [openal -> ] libopenal.so -> /tmp/jogamp_0000/file_cache/jln503156976055085139/jln6371865449741437183/libopenal.so: 990993 bytes, addedAsNativeLib: true
JNILibLoaderBase: addNativeJarLibs0(..) done, count 1, ok true
main - DynamicLibraryBundle.init start with: jogamp.openal.ALDynamicLibraryBundleInfo
NativeLibrary.findLibrary(<libopenal.so.1>, sun.misc.Launcher$AppClassLoader@1573872): null
NativeLibrary.open(): Trying to load libopenal.so.1
NativeLibrary.open(): Trying to load /usr/java/packages/lib/arm/libopenal.so.1
...
Why doesn't NativeLibrary.open() try to open the extracted native library? (In reply to comment #3) > Why doesn't NativeLibrary.open() try to open the extracted native library? b/c it didn't - a bug, fixed w/ gluegen abbe6ce0973fbd82971ace1866515beefcc41817 we came to same conclusion just now, very good that we all found the right culprit - nice. |
When JOAL cannot use the hardware accelerated implementation of OpenAL, it should use OpenALSoft as a fallback option. mbien claimed it worked some months ago but I still get the following exception: [java] Exception in thread "Thread-6" java.lang.ExceptionInInitializerError [java] at com.jogamp.openal.ALFactory.initialize(ALFactory.java:60) [java] at com.jogamp.openal.ALFactory.getALC(ALFactory.java:94) [java] at com.jogamp.openal.util.ALut.alutInit(ALut.java:66) [java] at paulscode.sound.libraries.LibraryJOAL.init(LibraryJOAL.java:154) [java] at paulscode.sound.SoundSystem.CommandNewLibrary(SoundSystem.java:1576) [java] at paulscode.sound.SoundSystem.CommandQueue(SoundSystem.java:2572) [java] at paulscode.sound.CommandThread.run(CommandThread.java:121) [java] Caused by: java.lang.RuntimeException: Couln't load native AL library [java] at jogamp.openal.ALImpl.<clinit>(ALImpl.java:2407) [java] .Initializing JOAL [java] (The JOAL binding of OpenAL. For more information, see http://joal.dev.java.net/) [java] .. 7 more [java] The initialization of the sound manager (based on JOAL) failed: paulscode.sound.SoundSystemException: SoundSystem did not load after 30 seconds. [java] Starting up SoundSystem... I don't know whether it is a bug or an enhancement.