OpenAL* classes single-threaded?


I just figured out a problem with some code we have. We want to play some background music, and this music has two parts: an introduction that gets things going, and a loop part that should be repeated indefinitely, and that should be started when the first part finishes. I don't think the solution we have in place is ideal, but it looks like this:

   introMusicTrack.addTrackStateListener(new TrackStateListener() {
      public void trackFinishedFade(AudioTrack track) {

      public void trackPaused(AudioTrack track) {

      public void trackPlayed(AudioTrack track) {

      public void trackStopped(AudioTrack track) {
         if (introPlaying) {

The intention being that when the first part of the track is finished, the second should be triggered - if we still want to play that music track at all. The problem was that even though we could see that the 'trackStopped' listener method was being called, we never heard the looping part play, and there were no messages in any log. It turned out that the listener callback was executed by a different thread than the one that played the rest of the sounds, and when we changed that - making sure that both calls to were done from the same thread - things started working again.

Is this the intended behaviour? If so, maybe there should be some checks in the OpenAL-related classes to ensure that users that make calls from 'the wrong thread' get notified about that?



Actually, this is a problem I'm not sure about either.  I believe that OpenAL is meant to be single threaded similar to OpenGL, but I do not have any documentation handy to prove this.  Can anyone confirm?

I have had some similar issues related to OpenAL with threading in the past.  I can't necessarily confirm that it is specific to OpenAL or the JNI work that was done, but there are definitely some issues here.

I've had some luck with being able to thread out my background music player apart from my sound effects engine. The trick was initiating openAL in a separate class first, and then being sure to reserve the appropriate number of sources for each so that you don't have to worry about synchronization. Of course, I ended up with other issues caused from the threading (my music streaming would occasionally stutter or poop out from "thread clashing" on machines that aren't as multithreading capable).