Can't get sound to work (LWJGL 3.2.1 build 12, Win10 64-bit)

Started by princec, February 15, 2019, 17:28:50

Previous topic - Next topic
Print
Go Down Pages 1 2
User actions

princec

#15
February 17, 2019, 15:27:26
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 :)

spasi

#16
February 17, 2019, 16:30:31
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 (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.

CoDi

#17
February 21, 2019, 09:27:55
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

princec

#18
February 21, 2019, 09:41:59
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 :)

spasi

#19
February 21, 2019, 10:32:59
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.

princec

#20
February 21, 2019, 10:35:46
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 :)

princec

#21
February 21, 2019, 12:23:43
It occurs to me that it might be GLFW that's the problem but that'll be harder to test.

Cas :)

princec

#22
February 22, 2019, 12:51:43
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 :)

Obsyd

#23
April 01, 2019, 17:47:19
Any news regarding this issue?

princec

#24
April 01, 2019, 18:05:47
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 :)

KaiHH

#25
April 01, 2019, 18:15:46
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.

princec

#26
April 01, 2019, 18:21:27
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 :)

spasi

#27
April 01, 2019, 19:43:19
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.

spasi

#28
April 01, 2019, 19:46:39
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.
Print
Go Up Pages 1 2
User actions