Skipping sound after upgrading from 1.4 to 2.0.1

[groves]

We upgraded lwjgl from 1.4 to 2.0.1 in the most recent update for our game.  Since the update, I've gotten several reports of sound being choppy and stuttering.  I've also gotten a few reports of CPU usage spiking dramatically when sound is played, but there aren't as many reports of that as there are of stuttering.  Thus far I've only gotten reports on Windows, but it runs the gamut from 2000 to XP to Vista, and has come from different revisions of Java 1.5 and 1.6.  Our bug reporting tool doesn't include sound card information, but I've gotten dxdiag dumps from a few players, and haven't seen any particular sound card or driver shared between them.

This definitely isn't happening in the majority of cases, and I can't get it to happen on any of the Windows machines I have access to.  Is there some further lwjgl logging I could add to the bug reports that might shed some light on why it's happening in some cases? Is there anything I need to do differently in the 2.0 series to hook lwjgl and openal libraries into Java or to set up the sound system?

[Matzon]

we started shipping openal-soft instead, which in theory use more cpu - but unless you're doing something really advanced, I have a hard time seeing why its happening. You best bet is to locate someone that gets the issue constantly and swap the OpenAL32.dll with one from creative (rename wrap_oal.dll to openal32.dll - openal32.dll is a router dll for wrap_oal, we dont use this feature and go directly with openal32.dll).

[groves]

The responses I've gotten so far indicate that the Creative library is much better.  Our sound usage is pretty light; we're only playing a few sounds at a time, and stream a longer sound every once in a while.  People do run the game using fairly ancient hardware, so that may account for the problems.  Is there any reason to use openal-soft?  Could I just switch back to the Creative library and keep using lwjgl 2?

[Matzon]

Yes, you can just use wrap_oal.dll (and rename it to OpenAL32.dll - or even no OpenAL32 and rely on a system installed OpenAL (if any)).

We switched to OpenAL-Soft because the "creative" linux oal version had a lot of issues and it was thought that using the same code base for all version (windows, linux, solaris) would be prefered.

I am still not sure that this is openal-softs fault, in cpu usage - maybe the shipped version has issues.

EDIT
Would it be possible to get a copy of the program in question?

I see you work for threerings, I assume this is related to Bang! Howdy? - how would I get a hold of the version that is based on 2.0.1 ?

[groves]

This is actually for Puzzle Pirates.  We started using OpenAL for sound in it about 6 months ago.  2.0.1 is being used in production now, so downloading it from http://www.puzzlepirates.com/download.xhtml will get you a version using it.

Also, you can also see the open source portion of the sound code we're using on the web.  We route all of our sound playing calls through http://code.threerings.net/svn/nenya/trunk/src/java/com/threerings/openal/OpenALSoundPlayer.java with support from the rest of the classes in that package. 

[Matzon]

so I had the game running for a long time and played a bit too - no problems.

Then I launched the app, fired up Intel Thermal Analysis Tool (TAT) and set processor load to 100% and within seconds I had stuttering (just a bit). I am talking to the main OpenAL-soft guy and see if there is anything to do. Though he did mention that: "someone did testing for me before the 1.6 release, and said he was able to play about 100 simultanious sources on a ~800MHz single core CPU without issue."

[Matzon]

right, so I found a "workaround".
The issue - I think, is in essence cpu starvation for openal. This can be offset by increasing the buffer that it works with.
For openal-soft, this can be controlled by the refresh property in its configuration file.
This file is called 'alsoft.ini' and is located in %APPDATA% (for windows - I assume ~/ for un*x ?). The path to the file can be controlled using the 'ALSOFT_CONF' environment variable.

My file looked like this:
refresh = 8192

which basically means I doubled the size of the buffers. This removed all of my stuttering.

You can see more in the sample config: http://repo.or.cz/w/openal-soft.git?a=blob;f=alsoftrc.sample;hb=HEAD