Cosmic Birdie Tech Demo Audio Test

WIP games, tools & toy projects Archived Projects
#21

Oh yes, we know something is different because the first app was a quick demo using HelloUniverse that showed the first JOAL error, where JOAL didn’t work at all in web start. It was a threading problem, which I put the fix in for, in both that demo and my engine. Then on testing we found that that fixed ALMOST everywhere but not this new issue. So Ken said that to really show the issue I woudl have to make an example with worked with LWJGL so I did. That is what the last demo is. And it worked so far everywhwere we tested.

Hoo-Ray (Maybe)

I think I nailed it.
Try the links again, even if you don’t have openAL installed! (And Ken will be happy to know his work is done! BIG THANKS to all)
If this works for everyone, then I guess I will post a summary, instructions .etc on my blog

So the issue it appears is the JOAL doesn’t load the OpenAL32.dll (in web start only?? maybe it fails for some reason?). I load it explicitly at start up before making a JOAL call. Now this is a windows only fix, so really the app has to have code for every (JOAL) supported OS and load the appropiate native lib. But really only the web start .jnlp checks for OS specific branches. And on a command-line launch, there is not normally checking because the version of JOAL you are running IS for that OS.

IN LWJGL OpenAL wrappers, you don’t have to do any system-lib loading. It’s taking care of it for you, so it just works, command-line and web start.
So I can fix this of course in our app, but it should ultimately be fixed in JOAL, unless it is in which case, I guess I don’t quote understand the real issue yet.

#22

JOAL works now, but I thought you said the sound should go away when the window comes up?

#23

It does in the first demo, the second one it can keep going, but the issue is getting it to start at all :slight_smile:
Good to hear it’s working for you. Let’s hope this does it.

#24

I’ll try it on my home systems tonight. Glad to hear it’s working in at least some cases where it wasn’t before. Maybe Ken can weigh in on whether JOAL is loading the OpenAL native library (I agree that it should do this).

– Kevin

#25

The thing that is weird is that it works command-line on all tested and on web start most machines without the user app doing a loadLibrary() (And even on those machines that failed, the other JOAL test always worked!).
So it would seem that JOAL must be doing it for those to work. But in some cases on some machines it’s not, and/or it fails…?

#26

JOAL currently doesn’t System.loadLibrary(“OpenAL32”) anywhere in its code. The joal_native.dll is linked against the OpenAL library. This means that JOAL currently expects OpenAL to already be installed on the machine. LWJGL does not have this limitation.

There is a technical problem with the loadLibrary call on UNIX platforms where the symbols in the DSO which is loaded aren’t visible to other libraries loaded with other System.loadLibrary() calls. This basically means that this workaround won’t work (even if you change the library name appropriately) on Linux / Solaris and probably not on Mac OS X either.

I’ve looked through LWJGL’s source code in the past and there is a significant amount of native code which replicates the System.loadLibrary() functionality presumably because of exactly this problem. I haven’t looked to see how the OpenAL32.dll or analogous DSO on Unix systems is found and loaded but assume there must be some trickery because Java Web Start controls where the unpacked DLLs/DSOs go.

I don’t know how the Jake2 team worked around this issue or whether they just punted it and assume OpenAL is already installed.

We can add the necessary code to JOAL to fully dynamically load the OpenAL DLL instead of requiring it to be installed. However I am personally under several tight deadlines for the next couple of weeks.

#27

So how do the JOGL web start jars get around this? They work correctly, no? (I’ve run JOGL demos but I’ve never made a web start one)

#28

Even though JOAL assumes OpenAL is installed, the times it didn’t work wasn’t because it wan’t installed, it was because ?, I dunno why it gave only the generic OpenAL error (no dialog) and then didn’t work. It wasn’t until I actually uninstalled OpenAL that I got an error that was usable, but the of course I know the .dll isn’t there anymore…

Understood.[quote]
I’ve looked through LWJGL’s source code in the past and there is a significant amount of native code which replicates the System.loadLibrary() functionality presumably because of exactly this problem. I haven’t looked to see how the OpenAL32.dll or analogous DSO on Unix systems is found and loaded but assume there must be some trickery because Java Web Start controls where the unpacked DLLs/DSOs go.

I don’t know how the Jake2 team worked around this issue or whether they just punted it and assume OpenAL is already installed.
[/quote]
Actually, in the Jake2 JOAL jars, it includes the OpenAL32.dll, which is why I tried packing that in mine to begin with. So Jake2 knows it’s there. At least on the windows machine.

Unfortunate, but understood. You have been a great help. You guys always are the best support group, free or paid!

But for the record, it seems as though JOAL is not usable with web start at this time…?

#29

JOGL assumes OpenGL is present which is a good assumption on all of the supported platforms. We do have a technical issue on Linux installations where we need to make sure libGL.so is dynamically loaded with global visibility to work with the open-source DRI drivers. We have added a bit of a hack to manually dlopen() libGL with RTLD_GLOBAL visibility before calling System.loadLibrary() for the JOGL native libraries. The reason this works is that OpenGL is always on the system’s default library search path.

#30

I would recommend you email them and ask them what they’re doing in this area, or just download the Jake2 source code and look at the JOAL initialization. If they’re doing anything which looks like it’s a suitable workaround for all platforms we’ll be glad to fold it in to JOAL.

It should be if OpenAL is already installed on the machine. I don’t understand the nature of all of the failures that have been reported here. As far as I understand it, JOAL was failing on machines where OpenAL wasn’t installed, which is what I would currently expect. If some of the machines where sound just “didn’t work” already had OpenAL installed, I don’t currently know what was going on there, as I wasn’t able to reproduce such failures on my setups.

#31

That’s exactly what I did to get this far. They explicitly loaded the OpenAL32.dll, so that’s what I added. Originally this had no effect. Until I uninstalled OpenAL… see below

Yes that is exactly the issue. Right now it fails on SOME machines (but the demos I made show it consistantly for each demo) that have OpenAL installed. Specifically, there are two demos, each loading and running ALMOST the same, one work ands one fails on many machines WITH OpenAL installed.
The difference in the demos was that one explicitly loaded OpenAL32.dll. I think there is some confusion because the only way to get an idea of what was going wrong you had to uninstall OpenAL because only then do you actually get a lib load error on the demo that failed.

However, the fix, which is to add a System.loadLibrary() into the user-app code, will not work anywhere else but on Windows as you explained, so that is not really a fix then.

I have since changed the links above with the system.load fix, but I can put it back right now so that the broken behavior is maintained and is testable.

It sounds like you are saying that the behavior we are seeing is the intended behavior, even though JOAL may fail when OpenAL is installed, but not as long as the user does a system.load.

If that is true, can someone put up a working web start JOAL demo where the app doesn’t explictly load OpenAL32 from the delivered jars and works on all platforms? Because from what I understand here, it is not possible (or rather it fails on some machines that have OpenAL installed) which to me means JOAL does not work with web start.

[mod]
Perhaps I should give a bit of context as to why I keep pressing this. To use Java for casual games, web start is the most ideal launch mechanism IMHO. To use web start for casual games AND the games core APIs, that stuff has got to work in some graceful way on 999 out of 1000 machines (that match the minimum specs). I have a series of machines to perform testing on, and on 2 out of 8 (Windows), JOAL fails in any configuration we set, with the soul exception of the app doing the lib load. Now that’s fine, I have workaround now and can continue development for now, but if there had been one doc that said “On Windows be sure to explicitly load the OpenAL32.dll in your app”, I would have saved two weeks of multiple people testing. To triple A game dev that amounts to nothing I suppose. In the indie world, that’s an eon, or damn expensive, however you want to look at it.

Since it sounds like there still isn’t agreement on this issue, then the best I can say is, “Well then please give me example code (that is using web start) that is done the way JOAL is supposed to be used and works (999/1000), because I can’t seem to do it.”

#32

I am completely in agreement with you that we need to make Web Starting apps using JOAL robust. I had no idea that this issue existed for machines that already had OpenAL installed. I’m surprised the Jake2 team’s solution works on Linux. I’d need to look at their complete source code. Maybe they catch UnsatisfiedLinkError to support the other platforms and assume it’s installed on those platforms. Regardless I’d like to make JOAL work even in the case where OpenAL isn’t installed as LWJGL does. This isn’t all that much work. I’ll try to get to it sooner rather than later.

#33

I wish I could’ve been more helpful, but alas, once I went to Java, I swore off my C/C++ skills and now… it’s dead Jim. :slight_smile:

#34

I apologize for how long this has taken but support for deploying JOAL via Java Web Start is finally in place. Please let us know if you run in to any problems with it.