Bug 608 - JOAL OpenALSoft fallback option missing or not working properly
Summary: JOAL OpenALSoft fallback option missing or not working properly
Alias: None
Product: Joal
Classification: JogAmp
Component: core (show other bugs)
Version: 1.0
Hardware: pc_all all
: --- enhancement
Assignee: Sven Gothel
Depends on:
Reported: 2012-07-24 12:50 CEST by Julien Gouesse
Modified: 2012-10-25 11:40 CEST (History)
2 users (show)

See Also:
Type: ---
SCM Refs:
gluegen abbe6ce0973fbd82971ace1866515beefcc41817
Workaround: ---

joal-jogamp.debug.log (14.87 KB, text/plain)
2012-10-25 01:01 CEST, Xerxes Rånby

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Gouesse 2012-07-24 12:50:23 CEST
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.
Comment 1 Xerxes Rånby 2012-10-24 22:19:08 CEST
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
Comment 2 Xerxes Rånby 2012-10-25 01:01:31 CEST
Created attachment 377 [details]

This is a fine bug in... gluegen.

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
Comment 3 Julien Gouesse 2012-10-25 01:30:48 CEST
Why doesn't NativeLibrary.open() try to open the extracted native library?
Comment 4 Sven Gothel 2012-10-25 11:40:53 CEST
(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.