I have a Dell Inspiron 17r laptop (and use the integrated Intel HD 4000 graphics), and time after time OpenAL fails to initialize with LWJGL3, while it worked fine with LWJGL2 (as far as I remember).
When I try to initialize OpenAL or attempt to play the We Shall Wake 7 demo, everything freezes up while trying to initialize OpenAL. (We Shall Wake loads past OpenAL around 1/10 times)
I also just installed the latest drivers two days ago. I am out of ideas, and would appreciate some input.
One thing you can try is replace OpenAL.dll in LWJGL 3 with the one from LWJGL 2. Does that fix the freezing? Btw, what is your operating system?
Windows 8.1 64bit
If I swap out the old DLL from LWJGL2, I get an ExceptionInInitalizer error with the following stacktrace:
Exception in thread "main" java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.ExceptionInInitializerError
at com.digiturtle.library.Utilities$Threads.runFor(Utilities.java:123)
at com.digiturtle.library.audio.AudioPlayer.create(AudioPlayer.java:40)
at com.digiturtle.library.Game.<init>(Game.java:71)
at com.digiturtle.library.tests.TestGame.<init>(TestGame.java:31)
at com.digiturtle.library.tests.TestGame.main(TestGame.java:168)
Caused by: java.util.concurrent.ExecutionException: java.lang.ExceptionInInitializerError
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:206)
at com.digiturtle.library.Utilities$Threads.runFor(Utilities.java:119)
... 4 more
Caused by: java.lang.ExceptionInInitializerError
at org.lwjgl.openal.ALDevice.create(ALDevice.java:71)
at org.lwjgl.openal.ALContext.create(ALContext.java:90)
at com.digiturtle.library.audio.OpenALAudioBackend.create(OpenALAudioBackend.java:30)
at com.digiturtle.library.audio.AudioPlayer$1.run(AudioPlayer.java:43)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: Failed to load library: OpenAL.dll (error code = 126)
at org.lwjgl.system.windows.WindowsUtil.windowsThrowException(WindowsUtil.java:28)
at org.lwjgl.system.windows.WindowsLibrary.<init>(WindowsLibrary.java:34)
at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:54)
at org.lwjgl.LWJGLUtil.loadLibraryNative(LWJGLUtil.java:164)
at org.lwjgl.openal.ALC.create(ALC.java:52)
at org.lwjgl.openal.ALC.create(ALC.java:48)
at org.lwjgl.openal.ALC.<clinit>(ALC.java:27)
... 9 more
Open the LWJGL2 dll or LWJGL3 one?
If I rename the LWJGL2 native to ‘OpenAL.dll’ it runs, but it still locks up.
EDIT: The last few tries seem to work, but I don’t know if that will continue.
EDIT 2: Still spotty, but I seem to have more luck when I run a program that is just this:
public static void main(String[] args) {
ALContext.create();
}
[quote=“CopyableCougar4,post:6,topic:55278”]
Both. See if the one from 3 has a dependency that’s missing. I want to see if the problem is with the dll (the one from 3 is a much newer build) or with something else.
[quote=“CopyableCougar4,post:7,topic:55278”]
Yeah, should have mentioned this. OpenAL.dll is the x64 binary, OpenAL32.dll is the x86 one.
More luck? As in, does it always work?
Just noticed from the stacktrace above that OpenAL is initialized concurrently from inside an Executor. This could be the problem, LWJGL 3 has no synchronization*. Could you share some code that’s similar to what you’re doing (but much simpler, no dependencies to com.digiturtle.library please)?
I do recall OpenAL sits on top of DirectSound APIs which require the a window handle and such to be initialised properly before they themselves can get initialised - wasn’t there some sort of hacky loop in LWJGL2 to sit and retry a few times until it worked?
Cas 
Yeah I can verify what cas says, it was the case at least like 3 years ago. Havent tried it in a while if that has changed.
Both DLLs talk about missing files when I open them in Dependency Walker.
It seems that when I run the program that just creates the OpenAL context, it has worked every time I try it. However the creation locking up happens more often when I create the context along with the GLFW/OpenGL context.
The executor service is me giving up on the OpenAL context creation after two seconds.
I cannot reproduce this, will need more info.
[quote=“princec,post:9,topic:55278”]
[quote=“Cero,post:10,topic:55278”]
I can’t find anything like that in LWJGL 2. Could you point me to a commit or forum post?
[quote=“CopyableCougar4,post:11,topic:55278”]
Do you create the OpenAL context before or after GLFW?
Try this code:
long defaultDeviceSpecifier = ALC10.nalcGetString(
NULL, ALC11.ALC_DEFAULT_ALL_DEVICES_SPECIFIER,
ALC.getFunctionProvider().getFunctionAddress("alcGetString")
);
System.err.println("DEVICE SPECIFIER: " + memDecodeUTF8(defaultDeviceSpecifier));
long device = ALC10.nalcOpenDevice(
defaultDeviceSpecifier,
ALC.getFunctionProvider().getFunctionAddress("alcOpenDevice")
);
System.err.println("DEVICE: " + device);
if ( device != NULL )
ALC10.nalcCloseDevice(
device,
ALC.getFunctionProvider().getFunctionAddress("alcCloseDevice")
);
Use it on its own in a simple main(), and also in your app (where you normally create the ALContext and it freezes). Also set the environment variable ALSOFT_LOGLEVEL to 3 before running anything. What output do you get?
'twas Brian that actually did that particular tweak as I recall… it was a long time ago though. Like 5 years or more.
Cas
I vaguely remember that post too and think the one being referred to is here.
A lot has changed since then and it might be that its been fixed in OpenAL-Soft now, although it looks like the code being referred to is still there.
DirectSound’s been deprecated by Microsoft for a while now so maybe its time for OpenAL-Soft to move to another backed on Windows, in recent versions of Windows its not even hardware accelerated anymore but emulated (therefore slower than it could be).
Thanks. I was able to reproduce this with ALSOFT_DRIVERS=dsound (default is mmdevapi on my machine). Fixed it by patching OpenAL-Soft to fall back to GetDesktopWindow() when GetForegroundWindow() returns NULL (this workaround is recommended by Microsoft). Will update the LWJGL build soon.
But I don’t think it’s related to CopyableCougar4’s problem. It simply makes alcOpenDevice fail, not freeze/block.
Spasi: I create the OpenAL context after the GLFW context.
Okay so when I run it by itself, this is what it says:
DEVICE SPECIFIER: Speakers / Headphones (IDT High Definition Audio CODEC)
DEVICE: 12725456
In the audio creation it says:
DEVICE SPECIFIER: Speakers / Headphones (IDT High Definition Audio CODEC)
DEVICE: 15792480
And just to double check, is this the way you want me to set the log level?
System.setProperty("ALSOFT_LOGLEVEL", "3");
Actually I take that back; I create the OpenAL context before the GLFW one.
Also, with 3.0.0b #15 I so far seem to be able to create the OpenAL context successfully each time. Although I will have to wait and see if that holds up.
[quote=“CopyableCougar4,post:17,topic:55278”]
No, it must be an environment variable. You can do [icode]set ALSOFT_LOGLEVEL=3[/icode] at the command line before running your app. You should be getting a lot of output in stderr if you enable it correctly.
Okay. I will be away from my computer today but I will run the program this evening.