Try as I might... no sound. LWJGL2.9 works, of course.
My init code:
String defaultDeviceName = alcGetString(0, ALC_DEFAULT_DEVICE_SPECIFIER);
LOGGER.finer(() -> "Default OpenAL device: " + defaultDeviceName);
long device = alcOpenDevice(defaultDeviceName);
if (device == 0L) {
throw new IllegalStateException("Can't open device " + defaultDeviceName);
}
int[] attributes = {0};
long context = alcCreateContext(device, attributes);
if (!alcMakeContextCurrent(context)) {
throw new IllegalStateException("Context cannot be made current");
}
alcCapabilities = createCapabilities(device);
alCapabilities = createCapabilities(alcCapabilities);
Prints "Default OpenAL device: OpenAL Soft", as expected. No errors seem to be raised with alGetError (and why should they - the rest of my code is unchanged from 2.9)
Cas :)
Hey Cas,
A few things to try:
1. Pass NULL to alcOpenDevice:
alcOpenDevice((ByteBuffer)null)2. Print the list of the available devices with:
List<String> devices = ALUtil.getStringList(NULL, ALC_ALL_DEVICES_SPECIFIER)and use one of those names with alcOpenDevice.
3. Enable OpenAL Soft's logging by setting the ALSOFT_LOGLEVEL=3 environment variable. More info here (https://github.com/kcat/openal-soft/blob/master/docs/env-vars.txt). Anything interesting in the output?
4. Use the OpenAL Soft shared library that comes with LWJGL 2. You can do that easily with -Dorg.lwjgl.openal.libname=<path_to_OpenAL64.dll>. Does that resolve the issue?
Firstly the AL debug output goes like this:
AL lib: (II) alc_initconfig: Initializing library v1.19.1-0da960c HEAD
AL lib: (II) alc_initconfig: Supported backends: wasapi, dsound, winmm, null, wave
AL lib: (II) ReadALConfig: Loading config C:\Users\foo\AppData\Roaming\alsoft.ini...
AL lib: (II) GetProcBinary: Got path: C:\Program Files\Java\zulu11.2.3-jdk11.0.1-win_x64\bin
AL lib: (II) ReadALConfig: Loading config C:\Program Files\Java\zulu11.2.3-jdk11.0.1-win_x64\bin\alsoft.ini...
AL lib: (II) GetConfigValue: Key disable-cpu-exts not found
AL lib: (II) FillCPUCaps: Detected max CPUID function: 0xd (ext. 0x80000008)
AL lib: (II) FillCPUCaps: Vendor ID: ""
AL lib: (II) FillCPUCaps: Name: "Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz"
AL lib: (II) FillCPUCaps: Extensions: +SSE +SSE2 +SSE3 +SSE4.1
AL lib: (II) GetConfigValue: Key rt-prio not found
AL lib: (II) GetConfigValue: Key resampler not found
AL lib: (II) GetConfigValue: Key trap-al-error not found
AL lib: (II) GetConfigValue: Key trap-alc-error not found
AL lib: (II) GetConfigValue: Key reverb/boost not found
AL lib: (II) GetConfigValue: Key drivers not found
AL lib: (II) ALCwasapiProxy_messageHandler: Starting message thread
AL lib: (II) ALCwasapiProxy_messageHandler: Message thread initialization complete
AL lib: (II) ALCwasapiProxy_messageHandler: Starting message loop
AL lib: (II) alc_initconfig: Initialized backend "wasapi"
AL lib: (II) alc_initconfig: Added "wasapi" for playback
AL lib: (II) alc_initconfig: Added "wasapi" for capture
AL lib: (II) GetConfigValue: Key excludefx not found
AL lib: (II) GetConfigValue: Key default-reverb not found
AL lib: (II) GetConfigValue: Key channels not found
AL lib: (II) GetConfigValue: Key sample-type not found
AL lib: (II) GetConfigValue: Key frequency not found
AL lib: (II) GetConfigValue: Key periods not found
AL lib: (II) GetConfigValue: Key period_size not found
AL lib: (II) GetConfigValue: Key sources not found
AL lib: (II) GetConfigValue: Key slots not found
AL lib: (II) GetConfigValue: Key sends not found
AL lib: (II) ALCwasapiProxy_messageHandler: Got message "Open Device" (0x0400, lparam=00000176856784F8, wparam=00000076531FF120)
AL lib: (II) GetConfigValue: Key ambi-format not found
AL lib: (II) alcOpenDevice: Created device 000001768BB05A50, "OpenAL Soft on Speakers (High Definition Audio Device)"
AL lib: (II) GetConfigValue: Key hrtf not found
AL lib: (II) UpdateDeviceParams: Pre-reset: Stereo, Float, 44100hz, 1024 update size x3
AL lib: (II) ALCwasapiProxy_messageHandler: Got message "Reset Device" (0x0401, lparam=00000176856784F8, wparam=00000076531FF020)
AL lib: (II) UpdateDeviceParams: Post-reset: Stereo, Float, 48000hz, 960 update size x3
AL lib: (II) GetConfigValue: Key stereo-mode not found
AL lib: (II) aluInitRenderer: HRTF disabled
AL lib: (II) GetConfigValue: Key cf_level not found
AL lib: (II) aluInitRenderer: BS2B disabled
AL lib: (II) GetConfigValue: Key stereo-encoding not found
AL lib: (II) aluInitRenderer: UHJ disabled
AL lib: (II) UpdateDeviceParams: Channel config, Dry: 2, FOA: 0, Real: 0
AL lib: (II) UpdateDeviceParams: Allocating 2 channels, 16384 bytes
AL lib: (II) UpdateDeviceParams: Max sources: 256 (255 + 1), effect slots: 64, sends: 2
AL lib: (II) GetConfigValue: Key dither not found
AL lib: (II) GetConfigValue: Key dither-depth not found
AL lib: (II) UpdateDeviceParams: Dithering disabled
AL lib: (II) GetConfigValue: Key output-limiter not found
AL lib: (II) UpdateDeviceParams: Output limiter enabled
AL lib: (II) UpdateDeviceParams: Fixed device latency: 1000000ns
AL lib: (II) ALCwasapiProxy_messageHandler: Got message "Start Device" (0x0402, lparam=00000176856784F8, wparam=00000076531FF020)
AL lib: (II) GetConfigValue: Key volume-adjust not found
AL lib: (II) alcCreateContext: Created context 00000176FF514110
Which to my mind looks like everything is good.
Cas :)
Also hampering my testing, I'm getting a ton of native crashes. It crashes 50% of the time, sometimes with a Hotspot error log, sometimes with bizarro VM corruption like being unable to find classes, sometimes just aborting without any explanation. I don't think this is related to the sound but it's hard to isolate. Here's an example:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb7f52b9c3, pid=1292, tid=20772
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13-LTS)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13-LTS, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [CoreMessaging.dll+0xb9c3]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Projects\Battledroid\hs_err_pid1292.log
#
# If you would like to submit a bug report, please visit:
# http://www.azulsystems.com/support/
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Cas:)
FWIW the hotspot log referred to there contains this:
Command Line: -Djava.util.logging.config.file=C:\Projects\Resources\logging.properties -ea --illegal-access=permit -Xss1m -Djava.library.path=C:\Projects\Common11\lib\windows64;C:\Projects\Steam11\lib\windows -XX:MaxDirectMemorySize=1024m -Xmx1024m -Xms256m -XX:MaxGCPauseMillis=1 -Dorg.lwjgl.util.NoChecks=false -Dspgl3.game.Launcher.resources=resources-steam.dat -Dspgl3.game.Game.gameResource=game.steam -Dnet.puppygames.steam.Steam.DEBUG=true -Djava.util.logging.config.file=C:\Projects\Battledroid\src-client/logging.properties -Dnet.puppygames.common.threading.TaskGraphBuilder.check=truex -Dfile.encoding=Cp1252 spgl3.game.Launcher
Host: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, 8 cores, 15G, Windows 10 , 64 bit Build 17134 (10.0.17134.556)
Time: Sat Feb 16 13:25:56 2019 GMT Standard Time elapsed time: 4 seconds (0d 0h 0m 4s)
--------------- T H R E A D ---------------
Current thread (0x00000210f6fcd800): JavaThread "main" [_thread_in_native, id=20772, stack(0x000000f809800000,0x000000f809900000)]
Stack: [0x000000f809800000,0x000000f809900000], sp=0x000000f8098fe630, free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [CoreMessaging.dll+0xb9c3]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.lwjgl.system.JNI.invokeV(J)V+0
j org.lwjgl.glfw.GLFW.glfwPollEvents()V+8
j spgl3.game.Display.processMessages()V+6
j spgl3.game.Display.update()V+3
j bots.client.Splash$1.execute()V+54
j spgl3.opengl.AbstractRenderer.build()Lspgl3/sprites/GeometryData;+117
j spgl3.opengl.GLRenderer.render()V+1
j bots.client.Splash.update(II)V+385
j spgl3.game.Game.init(Ljava/util/Properties;Ljava/io/InputStream;)V+802
j spgl3.game.Launcher.main([Ljava/lang/String;)V+247
v ~StubRoutines::call_stub
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x00007ffb00000050
Cas :)
- Does it always crash in glfwPollEvents()?
- Does it always crash in CoreMessaging.dll?
- Does it always crash relatively early in the game execution? I.e. while loading stuff in background threads or while JIT compilation is still happening.
- Do you launch the game from Eclipse? Does it crash when launching from the cli?
- Not always; it crashes in all sorts of totally random ways, in the manner of something clobbering memory randomly. VM crashes happen a lot but quite often it's in glfwPollEvents at the time. Might just be coincidence.
- See above
- Yes. Even running single-threaded.
- Yes, from Eclipse. Not tried CLI - will try that next.
- Also, sound mysteriously just started working 10 minutes ago. Didn't change anything. Stability however is still awful.
Cas :)
No difference from the CLI. Crashes similarly.
This minimal test code works fine, without crashing, which probably exonerates my display handling class that wraps GLFW:
package spgl3.game;
import java.io.File;
import javax.imageio.ImageIO;
import org.lwjgl.glfw.GLFWErrorCallback;
import spgl3.ui.Input;
class DisplayTest {
static GLFWErrorCallback errorCallback;
public static void main(String[] args) throws Exception {
errorCallback = GLFWErrorCallback.createPrint(System.err);
Display.setTitle("Display Test");
Display.setIcon(ImageIO.read(new File("C:\\Projects\\Battledroid\\src-client\\bd_icon.png")));
Display.create();
Input.init();
Mouse.setVisible(true);
while (!Display.isCloseRequested()) {
Display.update();
Display.sync(60);
Input.receive(new InputEventReceiver() {
@Override
public InputEventAction onMouseButtonEvent(MouseButtonEvent event) {
return InputEventAction.CONSUME;
}
@Override
public InputEventAction onMouseEnteredEvent(MouseEnteredEvent event) {
return InputEventAction.CONSUME;
}
@Override
public InputEventAction onMouseWheelEvent(MouseWheelEvent event) {
return InputEventAction.CONSUME;
}
@Override
public InputEventAction onMouseMovedEvent(MouseMovedEvent event) {
return InputEventAction.CONSUME;
}
@Override
public InputEventAction onKeyTypedEvent(KeyTypedEvent event) {
System.out.print(event.getCharacter());
return InputEventAction.CONSUME;
}
@Override
public InputEventAction onKeyEvent(KeyEvent event) {
return InputEventAction.CONSUME;
}
});
}
Input.cleanup();
Display.cleanup();
}
}
Cas :)
Sounds similar to http://forum.lwjgl.org/index.php?topic=6871.0, which is still without explanation. Could you please try some of the possible workarounds mentioned there? (e.g. running with -XX:-CriticalJNINatives and/or -Xcomp, running with parallel instead of G1GC)
-Xcomp : same symptoms
-XX:-CriticalJNINatives : same symptoms
Also, sound mysteriously stopped working again :P
Cas :)
Tried -Xint too, so that rules out the compiler and probably therefore the JRE itself.
Cas :)
Same problem with LWJGL3.2.0.
Cas :)
Ok, LWJGL 3.1.6 is fine, in as much as I've just run everything 10 times and not had a single crash whereas 3.2.x would crash 80% of the time.
Still no sound tho' :P
What changed between 3.1.6 and 3.2.0?
Cas :)
LOL, ignore me about the sound, I'd turned down the bloody volume to take a call. Sound is now fine, LWJGL is now fine, seems you have a massive memory crapping problem in 3.2.x though and I can't even begin to imagine how to start diagnosing it.
Ca s:)
I've reviewed all changes that went into 3.2.0, nothing stands out. Some things that might help:
- Which LWJGL bindings do you use? I'm guessing the core + GLFW, OpenGL and OpenAL only so far?
- Is there an unusual number of string encoding/decoding happening around the time it crashes?
- Are there multiple OpenGL contexts in use when it crashes?
- Would it be possible to produce a trace of LWJGL methods that Battledroid calls?
- A way to test this locally would be very useful. Could we work out a way for me to try a cut-down Battledroid build that reproduces the crash?
Yes, I'm using minimal LWJGL - core, GL, AL, GLFW only at this stage.
Nothing fancy is going on regarding strings. Quite often it doesn't even get as far as loading source code to the shaders as it crashes before it even gets a window up.
There's only one context, and usually when it crashes, still only one thread doing any work (tried singlethreaded too, same results).
In short there was no combination of things I did or disabled or properties set that fixed it other than simply trying 3.1.6, when everything worked exactly perfectly, first time (sound included).
I need to do a bit more work to get the project to build properly (getting theagentd to try running it from Eclipse was a bit of an eye-opener as to how much of a faff that was) but then I can easily deploy it to Steam for you. Getting to the bottom of this would seem to be of extreme importance because it does rather look like right now the entire 3.2.x is totally broken and has been for a while!
Cas :)
Quote from: princec on February 17, 2019, 15:27:26I need to do a bit more work to get the project to build properly (getting theagentd to try running it from Eclipse was a bit of an eye-opener as to how much of a faff that was) but then I can easily deploy it to Steam for you. Getting to the bottom of this would seem to be of extreme importance because it does rather look like right now the entire 3.2.x is totally broken and has been for a while!
That's great, thank you. Obviously, I'll be deeply disheartened if this turns out to be a bug in LWJGL. It would mean the testing I perform is lacking and I can't depend on the community to promptly discover and report such issues.
One more thing you could try: LWJGLX/debug (https://github.com/LWJGLX/debug) (direct download: https://build.lwjgl.org/addons/lwjglx-debug/lwjglx-debug-1.0.0.jar). Run with:
java -javaagent:lwjglx-debug-1.0.0.jar <...normal arguments..>Assuming no obvious error pops up until it crashes, you can enable tracing with:
java -javaagent:lwjglx-debug-1.0.0.jar=t;o=trace.log <...normal arguments..>Review the log (to remove sensitive information if necessary) and attach it here or in a PM. KaiHH was kind enough to do a couple of fixes earlier, the trace will now include all LWJGL calls. This will help me focus the investigation to what's actually being used only.
Quote from: spasi on February 17, 2019, 16:30:31
Obviously, I'll be deeply disheartened if this turns out to be a bug in LWJGL. It would mean the testing I perform is lacking and I can't depend on the community to promptly discover and report such issues.
Just dropping in to note that we are running Pathway builds on LWJGL 3.2.0 (with a modified libGDX 1.9.9) since half a year now, and I didn't hear of such trouble. Between our dev team, external contributors and our publisher, this has been running on quite a number of systems already, so I would be surprised if this is a widespread problem.
I don't know if it helps, but here's my OpenAL setup code:
https://gist.github.com/code-disaster/a14993f38966ba06fa4f579820f89d43
I noted a couple of things:
- my call order (device, context) is slightly different to yours
- I run audio on a separate thread, so there are thread context calls
- that retry loop is because we've had a problem on some systems that device creation would fail on the first try, but succeed after a short delay
It isn't the AL library that's the problem it turns out though, that actually works perfectly well on 3.1.6 (and removing AL from the game didn't fix it in 3.2.x).
It very much looks like the problem the Minecraft guys were running in to in the thread Spasi linked to back up the thread.
As to why it "seems" ok... this is the peril of native code - it probably isn't, you've just been lucky enough that whatever memory corruption is occurring hasn't blown up for enough users that they've started complaining at you yet :) You'd be surprised how gamers are conditioned to just accept crash bugs and shrug and restart from the world of AAA...
I'm slowly working towards getting a build together but I'm a bit busy working for The Man right now and other things.
Cas :)
Quote from: princec on February 21, 2019, 09:41:59It very much looks like the problem the Minecraft guys were running in to in the thread Spasi linked to back up the thread.
They're having crashes with 3.1.6 too though. Also:
QuoteIt seems to be exclusive to development type environments, where the game is launched from either an IDE or gradle.
The peculiar thing about running from an IDE is that if you do look at the actual process that the IDE spawns, and its commandline, there's absolutely nothing different to how it looks than if it were launched from a command prompt. So again... possibly just random luck here.
Cas :)
It occurs to me that it might be GLFW that's the problem but that'll be harder to test.
Cas :)
OH NOES!!!!11!!!
It's just randomly started to go wrong with LWJGL 3.1.6 now too :( No reason for it... was working last time I tried. Now it's not.
Cas :)
Any news regarding this issue?
The news was, it was "my fault", except that the LWJGL API makes it a) very easy to get wrong b) doesn't check and c) gives you all the fun of C memory corruption and everything that entails. Personally I don't think it's a great way to do things but I've fixed it and moved on.
The bigger picture is that there are so many ways to get this wrong in the whole of the LWJGL API surface that there's no way anyone sane would condone its use, but LWJGL is what it is and nobody's about to change it.
Cas :)
I'd really be interested in the actual specifics of the usage error. I am trying to further the development of the LWJGL 3 "validation layer" project: https://github.com/LWJGLX/debug and for that, feedback from actual projects is invaluable to drive development of new validations/checks.
I never did really figure out exactly what was wrong, some combination of API calls to do with setting an icon on the GLFW window caused it to blow up - I just got it working by using the "right" combination of voodoo and moved on.
Problems arise around the dichotomy of Java scoping and stack scoping, which are orthogonal concepts that have unfortunately been mixed up in the API.
Cas :)
KaiHH: the problem was explained here: http://forum.lwjgl.org/index.php?topic=6871.msg36237#msg36237. An instance returned by GLFWImage.create was used in a try-with-resources block. For LWJGLX/debug, you should be able to detect the .close() call (which delegates to .free()) in the automatically generated finally block.
Btw, the debug allocator is catching this as an error (trying to free an allocation the allocator doesn't now about), but you may be able to produce a more useful/friendly error message.