Ditto for the second method: personally I keep my GL stuff out of the constructor and have GL stuff happening in init/render/delete(GL) methods.

I think you also have to enable multisampling if it's supported:

if (gl.isExtensionAvailable("GL_ARB_multisample")) {
   gl.glEnable(GL_MULTISAMPLE);
}

It should be possible; I think there's even a JOAL demo that does that sort of thing.

Maybe take a look at the JOAL demos package as it has a Java version of the EFX demo from the OpenAL 1.1 SDK.

Yeah, out-of-date tutorials are never cool.  That might be something nice to put on the to-do list, as well as making JOAL run when only OpenAL 1.0 drivers are found.

Unfortunately, the go-to guy for JOAL (and JOGL) maintenance has been assigned to work on the ambitious Java 6 update 10 release, and so fixes for even trivial things like the tutorials won't get fixed any time soon.

Unless I've misunderstood the question, can't you use JNI to do this sort of thing?

The number of sources available to you is hardware dependant.  There is an OpenAL function to let you know how many sources are available... but I currently don't have the OpenAL SDK and it's docs installed   I'm guessing it'll be one of the alGet() or alcGet() functions, when passed one of the constants, named something like NUM_SOURCES.

(will edit this post once I re-install SDK and find the appropriate functions/constants)

[EDIT]: Maybe I'm going crazy, but I can't seem to find what needs to be done to get the number of sources.  I'm sure you can keep calling alGenSources() until it starts returning errors, but that doesn't seem like a nice solution.

[EDIT again]: This site (http://btanks.sourceforge.net/blog/2007/08/28/openal-programming-faq/) lists it as something like the following (my rough translation from the C/C++ code on the site):



The values in attributes[] will be ordered as follows:
ALCint attrs[] = {
    ALC_STEREO_SOURCES, stereo_sources,
    ALC_MONO_SOURCES, mono_sources,
    ALC_INVALID, ALC_INVALID
};

So I guess the number of (mono) sources will be in attributes[3].

You don't really make a multi-threaded JOGL program (ie: multiple rendering threads, because that doesn't work), but rather a multi-threaded program with one thread dedicated to OpenGL rendering (eg: one thread for OpenGL operations, another for audio, and however many else you need for the rest of your program).

OpenGL operations can only be done on the thread that has the OpenGL context as 'current'.  If you're using the GLEventListener interface (which I assume you are because you have a display(GLAutoDrawable) method), then the context is current when any of the interface's methods are called: display(), init(), reshape()...
It is in these methods that you should do your OpenGL operations.

Basically, you can't create a new thread and make that do the drawing for you because that new thread will not have a 'current' OpenGL context.  If you want, you can perform a context switch (eg: make the 'current' thread release the context, and then make it 'current' on the thread you made before it does it's rendering), but doing so isn't the way to make your program multi-threaded.

So you're using the sound3d package in JOAL?
Hmm you're right, I don't see a getSourceID() in there, or anything to give you the source ID of the Source.  That's quite annoying actually.

Maybe you could make your own Source object, one that'll give you access to the source ID.  Or, modify the source code of the existing JOAL sound3d package: source ID is a private final field in there, and it'd be a really quick change to add additional cone functions like you wanted, or to retrieve the source ID for other functions.

The OpenAL programmers guide has:
AL_CONE_OUTER_GAIN       f, fv            the gain when outside the oriented cone
AL_CONE_INNER_ANGLE    f, fv, i, iv    the gain when inside the oriented cone
AL_CONE_OUTER_ANGLE   f, fv, i, iv    outer angle of the sound cone, in degrees default is 360

So you'd use alSource(f/fv/i/iv) for those, eg:

al.alSourcef(sourceid, AL_CONE_INNER_ANGLE, 1f);
al.alSourcef(sourceid, AL_CONE_OUTER_ANGLE, 30f);
al.alSourcef(sourceid, AL_CONE_OUTER_GAIN, 1f);

(the float values I'm passing are just examples, I don't even know if they're valid)

By 'not implemented', do you mean that they throw some exception when you try to use them?  Or they just don't seem to have any effect?

I'm curious if the first of the bold lines actually compiles: alGetSourcei() has a void return type, and so that line shouldn't even work.  Maybe you're using an older version of JOAL built against OpenAL 1.0?
Anyway, the error you're getting must be AL_INVALID_ENUM because of the 3 constants you've listed, it's the only one documented for the alGetSourcei() method.

I've just tried using AL_SOURCE_TYPE as the enum parameter, and was able to get the source type from that method without error.  Maybe using AL_SOURCE_TYPE in alGetSourcei() is an OpenAL 1.1 thing (AL_SOURCE_TYPE isn't listed as one of the valid parameters for that method, but I just think that's the documentation lagging behind the API) ?
I'm using JOAL 1.1.2 (a nightly build from early November).

I don't know the j-ogg API that well, but from what you say and the little I've read, it would seem that yes, you'll have to get a new stream since resetting isn't supported by the VorbisInputStream.

[EDIT]: I was just thinking that maybe you could wrap the VorbisInputStream with an InputStream that does allow resetting, but the only ones that come to mind store the entire stream to memory.  Kinda defeats the purpose of streaming then.

I would've thought that applying the looping property - alSourcei(sourceID, AL_LOOPING, AL_TRUE) - would be enough, but it might not apply to a streaming.  However, reading the OpenAL programmer's guide states that "As long as there is always a new buffer to play in the queue, the source will continue to play."  With that knowledge, maybe it's just enough to find-out when you've queued the buffer from the end of the file, so that you start queuing buffers from the start of the file immediately after it.

Wrong forum mate

I'm no OpenGL expert, but from what I've read, offscreen rendering is just that: offscreen rendering.  This means drawing pixels to an area that cannot be viewed by the player at all, such as a pbuffer (pixel buffer?), but are still rendered directly to the videocard's memory.  Obvious advantages are that texture copying can be done within video memory instead of hauling it around system memory -> CPU (especially if your videocard has the render-to-texture extension), but now you have to be responsible for managing your videocard's memory.

[EDIT]: This is the JOAL (OpenAL) forum.

If you want to use JOGL directly, then the short answer is yes.  Although learning OpenGL isn't difficult; it's just an API and not a language, and even though most of the tutorials you'll find were written in C++, it's really easy to find the JOGL equivalent of everything.

As for indirect use of JOGL through a scenegraph of other library which has attempted to build objects and other things which make it easy for any OO programmer to pick-up, then, depending on that library, almost no OpenGL knowledge is required.

While I haven't given it a try myself, I believe the FIXME in the GLCanvas class arose from the situation described in the NeHe tutorial about antialiasing: http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=46  Basically, you can't query the pixel format (to see if multisampling is available) until the window is created, but you can't create a multi-sampled window unless you know the pixel format.  I came across something similar in the SWT bug reports, but that was in 2005 between one of the SWT OpenGL guys and Mithrandir of these forums: https://bugs.eclipse.org/bugs/show_bug.cgi?id=110757#c23

Maybe if you can figure a way around that situation, you could create your own OpenGL Canvas object that overrides SWT's GLCanvas (provided that SWT allows overriding of the GLCanvas, I know SWT throws SWTException if you try to override many of it's widget classes).

I'm inclined to believe that this may be a SWT problem as I've experienced the same sorts of things you've just described: anti-aliasing cannot be enabled on my SWT app unless I use the nVidia Control Panel and force it on. ie: I cannot have application-controlled anti-aliasing using SWT.  I've also noticed that setting the GLData.samples and GLData.sampleBuffers seems to have no bearing on the number of mutisample buffers and samples that are in OpenGL app: it all just ends-up at 0 unless AA is forced via the nVidia Control Panel.

[EDIT]: Just took a look in the GLCanvas code to see what becomes of the GLData object, and lo and behold:


   //FIXME - use wglChoosePixelFormatARB
//   if (data.sampleBuffers > 0) {
//      wglAttrib [pos++] = WGL.WGL_SAMPLE_BUFFERS_ARB;
//      wglAttrib [pos++] = data.sampleBuffers;
//   }
//   if (data.samples > 0) {
//      wglAttrib [pos++] = WGL.WGL_SAMPLES_ARB;
//      wglAttrib [pos++] = data.samples;
//   }

JOAL will still work if the WAVLoader was rewritten to use indirect buffers.  JOAL doesn't make any distinction between the 2 when converting them into OpenAL buffer objects.

The 2D asteroids tutorial by Kevin Glass (http://www.cokeandcode.com/tutorials) helped me get passed that initial hurdle.  From then on my own design philosophies and continued learning have been enough to see me through.

And a good book is always something I look out for.  I ended-up buying those 2 OpenGL books advertised on NeHe's site (http://nehe.gamedev.net/, which is also a good OpenGL learning resource) to help me figure-out OpenGL, and I was almost going to get that Ogre3D (http://www.ogre3d.org/) book to learn the hows and whys of their scenegraph so that it could help me when I was making my own.   The Ogre3D book turned-out to be a bit pricey at my local bookseller, so I made use of the Ogre online resources instead (wiki, docs, as well as downloadable source code) which are rich and plentiful.

If we're just going by the date of the downloads listed, then yeah, there's nothing there for the month of December.  Latest is either April or September, depending on how you read that date.

sleep() isn't bad, but you have to remember that when you call sleep(), you're doing a whole lot more than just pausing that thread's execution.

I can see where the error occurs in the JOAL source code, and it does try to allocate a direct buffer to your wave file.  What size are the wave files you're trying to load?
Maybe you could try loading the files into indirect buffers by copying the JOAL source code that does the file loading, and just replacing the ByteBuffer.allocateDirect() method with ByteBuffer.allocate().

As for the unloadWavData() method, that method doesn't seem to exist anymore with the latest JOAL.

Replacing the Animator isn't at all difficult: it's just a thread where the OpenGL context is current and continuously calls the rendering methods of your app (which if you've been using the GLEventListener stuff is the display() method).

I remember reading somewhere that JOGL uses something of AWT: something about event dispatch threads?  I forgot.  The result being that JOGL + SWT apps used to lock-up on Mac machines.
I don't know if this still occurs with the latest JOGL RC.

2 things come to mind:

 - alcCaptureCloseDevice is an OpenAL 1.1 function.  Maybe installing an OpenAL 1.1 driver for your soundcard might help?
 - the 'caused by' part of the stack trace points to the lines in the JOAL code which indicate that an OpenAL driver couldn't be found at all.  Installing OpenAL and making sure the OpenAL libraries are somewhere on the library path (although the installation should already do that) should help here.

If you're not using JOGL's Animator and GLEventListener classes, then choosing a thread to become your rendering thread is up to your app.  Otherwise, I imagine you'll have to make some source code modifications to JOGL, or even the JDK.

The demo you're running, EFXFilter, requires the EFX extension which is a feature of OpenAL 1.1.  Do you have OpenAL 1.1 drivers installed for your soundcard, or the OpenAL 1.1 software driver (emulates OpenAL 1.1 functions using your CPU, available here: http://www.openal.org/downloads.html ) ?

I couldn't find version information in the downloaded file either, or in some of the older SWT OpenGL posts, but the SWT port is usually a couple of release-candidates (maybe even a minor version) behind the current version of JOGL.