OpenAL and current LWJGL-based tools

Java Sound & OpenAL
#1

I made a working endless, non-repeating campfire sf/x, and it runs on the OpenAL that comes with LWJGL 3. First get it to work, then improve it, right?

If I understand correctly, there are basically four “layers” that require handling for sound:

device
context
source
buffers

I was puzzling out what should be handled automatically by the class and instance, and what should be provided by the programmer. I’m figuring, since the “source” is given a 3D location, maybe it should be accessible to the programmer (sometimes audio cues need to be moved around). Also, possibly the programmer may be organizing sources into various “contexts.”

I’m thinking the cue instance should require the programmer to provide these values as arguments to the constructor. The constructor would then handle setting up the streaming buffers so that the game developer wouldn’t ever have to deal with that level of detail, they would just start or stop the CampfireSFX.

But it seemed to me that this could be a lot to ask of the game developer, especially if they had signed up for a library to help shield them from managing these details.

So…I thought the thing to do would be to see how the various game engines handle “device” and “context” and “source”. First look was at a Slick audio example and…full stop: it is using LWJGL 2, not 3.

A quick look at our JGO “OpenGL” forum shows the first entry as LWJGL 2.9.2.
Does Libgdx also still use 2.9.2?
Does JMonkeyEngine also still use 2.9.2?
If so, are there plans to migrate to 3?

It is not clear to me from the documentation what versions of LWJGL these engines are using. I guess I just need to go ahead and download them and see what I get…

#2

Firstly game engines will generally never expose “device” or “context”. So you can neatly sidestep thinking about that.

That leaves a game programmer the general concept of a “source” of sound, and in general you’ve got the following sorts of sounds in games:

  1. Background music, streamed from a simple stream
  2. Background ambient effects, streamed from a location in space
  3. Foreground effects, one-shot or looped from a location in space
  4. UI effects, one shot, no location

Cover those four cases and that’s 99.99% of everyone’s needs sorted.

Cas :slight_smile:

#3

@princec I don’t know why I didn’t your this reply until just now!

I was glad to learn that libgdx now uses lwjgl 3. I can’t recall what post that was from.

Here is an example of what I was trying to think through:

I have an SF/X that could work for a torchlight mounted and burning on a castle wall. As there are many torches in a dungeon game, there would be reuse of the cue. Because of the way OpenAL is implemented, it would require polling and populating buffers associated with each Source object (annoying and something a game application programmer shouldn’t have to bother with), and we’d have to have a Source for each torch location as the Source holds the data used for 3D panning and volume calculations.

The logic for whether a given torch is heard or not would be kind of similar to the code used to determine if it is visible or not. At the edge of “earshot” we’d set up and launch the buffer streaming for the sound. The code to do this should probably be just the flipping of a switch if within earshot.

So, the API I would provide for a TorchBurningSFX would include setting a location, and a switch to flip it on or off, and maybe some additional ways to extend or vary the quality of the sound (letting OpenAL handle the volume and panning as needed for the 3D).

Then, it would be up to the game programmer to do something like update the switch based on monitoring the distance, e.g., turn it off it more than 150 something away, turn it on if within 120 something away (am making up numbers). The gap (150-120 or whatever) would be to lessen the amount of overhead/thrashing that comes from dancing back and forth over edge case. But that sort of decision would be left to the application programmer.

Does this sound like a good plan?
I’d also provide a getSource() method for programmers wishing to directly work with the Source properties.

I’m working on some “weather” effects right now. Hope to get back to trying some sort of SF/X for OpenAL in the next few weeks.