JOAL Update

Java Sound & OpenAL
#1

For a while the JOAL project, due to the lack of a maintainer, has been in maintenance mode (if that). I would like to propose resuming active development on it.

The initial JOAL implementation done some two years ago was basically done by hand. At one point the JOAL source tree was converted over to use the same GlueGen tool which the JOGL project uses to autogenerate its Java interfaces and JNI code, but this work was only done on a branch of the JOGL tree and was never promoted to the main trunk.

I’ve revived this work and have a JOAL workspace which uses the current GlueGen tool being used by JOGL and the JSR-231 proposed reference implementation. All of the utilities and demos have been converted over to the new APIs and seem to be working fine. As a bonus the demos should now be web-startable.

The new workspace has some public API changes compared to the current one. The ALC.Device and ALC.Context inner classes have been promoted to top-level data types (ALCdevice and ALCcontext) as is the glue code style in JOGL. The mappings of e.g. void* to Buffer which are done in JOGL are now done in the new JOAL workspace. I took the liberty of cleaning up some unused / unneeded methods in the ALut and ALFactory classes as well as some other cleanups. The headers have been upgraded to OpenAL version 1.1 and the lookup of the function pointers has been automated.

One slight downside of this change is that it currently requires a built JOGL workspace to be a sibling of the JOAL workspace, in order to pick up the GlueGen tool out of the JOGL workspace. We hope to split off the GlueGen tool into its own project on java.net so this would not be required forever.

I would like to check in this work on to the main trunk and increment the version number to 1.1.0 from 1.0.0 to indicate an API change. All in favor, please say ‘aye’. If you have any objections to this, please post them.

#2

This sounds like a very good idea!

// Gregof

Edit: Aye!

#3

FYI, the new code has been checked in under the gluegen-branch-1-0 branch. You can see it via


  cvs co -r gluegen-branch-1-0 joal

(with appropriate CVSROOT, etc.).

I don’t have Developer privileges on the joal-demos workspace yet so can’t check in the new versions, but it’s a pretty mechanical transformation to the new APIs.

Hopefully with some more feedback we’ll promote this branch to the main trunk after the holidays.

#4

This is a very good idea.

javax.media.opengl.*
and
javax.media.openal.*
and
webstart

I say, Aye

bye
Carsten

#5

Thanks for your feedback. However, the namespace for JOAL will not change as there is no JSR for it underway. One could certainly be done, but for the time being the intent would be to check in the new APIs into the existing net.java.games.joal package.

#6

The GlueGen-based port of JOAL has been merged on to the JOAL main trunk. We hope to have nightly builds of JOAL available again soon. We are also working on splitting the GlueGen tool now used to autogenerate both the JOGL and JOAL APIs into its own java.net project, which will make it easier to build the JOAL workspace.

#7

Just converting over our old code. The method alcFreeCurrentContext() is MIA. What’s the replacement strategy for dealing with returning the AL content to the non-current state now?

#8

alcMakeContextCurrent(null) should do it. It looks like the previous alcFreeCurrentContext was a convenience routine not in the core OpenAL spec.