I have begun looking into Javasound and have download a bunch of sourcecode I am going to dig through. Specifically I am looking for ways to do the things that SoundManager already does: Multiple Sources; Pause, Play, Rewind, and Stop; normal playback of WAV and OGG sounds; and streaming playback of OGG sounds. I'm also going to look for a function for changing source volume - if I can find that, then Javasound could potentially support Linear Attenuation for a simi-3D sound system. If I get really ambitious, I might even write my own Logrithmic (Rolloff) Attenuation algorithm. That way the only difference between the OpenAL and Javasound systems would be the "true 3D" left/right fading for mono sounds that OpenAL supports -- something that, at least on my soundcard, doesn't seem to work very well anyway
I'm going to start by writing test programs to learn the skills needed to use Javasound. After that, I will begin incorperating the code into SoundManager. The later task will not be trivial, mind you. I hadn't originally planned to use multiple sound libraries when I designed the class, so there will have to be some significant structural changes.
While I'm restructuring the class I also plan to address any other bugs that are discovered. I'm hoping a few people will give me feedback on the helicopter demo applet, or even better on any of their own projects they are using the SoundManager class in. One potential bug I noticed yesterday is that often a ball will bounch quite close, but I don't seem to hear a nice "Boing" when it happens. I'm not sure if this is a logic problem specific to that applet (using Math.sin() always gives me a headache), or if it is a systematic problem with the SoundManager. Thinking back, I did do a ton of testing with looping sources because of the complexity involved with managing them. As a result of this special attention, looping sources seem to work quite well now (the flying cubes applet works beautifully with the latest version of SoundManager). However, I may not have done enough testing for the simple non-looping non-streaming sources, so I will go back and look at those types of sources more closely. Could be a delay issue (between when the command is queued and when it actually gets executed), could be a channel issue (didn't cull sources correctly before trying to play), or could be a logic issue (told too many sources to play, filled up channels, didn't cull the right ones). Hard to say at this point, but I am sure to find the cause if I dig into it a little further.
--- UPDATE ---
I found the cause for this "boing" problem. It is due to some flawed logic on my part, related to the fact that the command-processing thread runs seperate from the source-management thread. What's happening is whenever several balls hit the ground at the same time, commands are queued to play more sources than there are available channels. Because there are not enough channels, some of the sources do not play.
When using the active-culling management model, the source-management thread goes through the list and culls the far-away sounds, freeing up channels. At this point, if these were looping sources, source-management would then reactivate the closest sources. Problem is, these are not looping sources, and SoundManager does not reactivate non-looping sources (to avoid sound effects being repeated if they happen to be located at a position where they alternate back and forth between culled and active). So basically, if OpenAL was not able to play them before, they simply do not play at all.
Something similar happens when using the channel-monitoring management model. As before, the channels get filled up with a bunch of sources (not necessarily the closest ones). Now, if these were looping sources, the management thread would play the closest ones as soon as channels became free. But since they are non-looping sources, SoundManager does not play them when channels open up (to avoid a potential time-delay between when the sound was supposed to play, and when it actually does). So like in the active-culling management model, if OpenAL was not able to play the source before, it does not play at all.
Ok, so all this sounds rather complicated. Well, actually this is an easy fix. Instead of having the command processor actually playing a source, I'll just have it set a "toPlay" boolean for the source. Then the source-management thread can actually play the sources after making a decision which sources should be played. Only thing I'll have to make sure of is that the entire process from queueing a command to play, and when the sound actually comes out of the speakers, happens fast enough. There's nothing worse than firing your lazer cannon, then hearing the blast half a second later (brings to mind the scene from Star Wars, Attack of the Clones, where Jango Fett was setting off seismic charges in the asteroind field)
--- END UPDATE ---
I'll keep you posted on my progress. Development on the SoundManager may slow down just a bit, because starting this week I am going to begin working on some other components for my game, but I will try and manage my time so SoundManager is completed in a timely manner.
Thanks for all the great help and tips you guys have been giving me. Relatively small community here, but the jPCT forums are my favorite by far.