AL10.AL_BUFFERS_PROCESSED broken since lwjgl2.0 ?

[dronus]

Hello,

I have a sound engine working well for some time, however since lwjgl2.1 its broken:

For a source with some buffers enqueued, AL10.alGetSourcei(source, AL10.AL_BUFFERS_PROCESSED) allways returns zero, tested on several Linux 32bit systems. The enqueued buffers are repeated forever.

I already downgraded from lwjgl 2.1 to 2.0 because of this. Now checked lwjgl2.2.1,  still has this problem. I can switch the bug by exchanging lwjgl.jar and the native libs.


The app can be downloaded here:
http://vis.hfbk.net/vis/release_candidates/
It extracts itself to /tmp/VisClient. When running, press the wrench symbol in the lower right and enable the checkbox "sound", press OK.  You can now drag an mp3 file to the 3d view, it should play. However it doesn't. It does again, if the lwjgl.jar and natives in /tmp/VisClient
are replaced by good'ol 2.0rc2 ones.

The bug occurs in: https://snr.freifunk.net/trac/vis/browser/VisClient/org/dronus/al/ALAudioThread.java?rev=4134 line 133 .


Any ideas? Else I will dig into lwjgl sources to hunt this down.


thanks & nice xmas

dronus

[dronus]

Ok, got a clue: It's libopenal.so that breaks my code over lwgjl 2.0 to 2.2.1.

By replacing just libopenal.so with the lwjgl2.0rc2 build, I can get it running with lwjgl2.2.1 again, libopenal.so still compatible...  So it seems OpenAL team should address this, but maybe I am doing something wrong and the old AL is more tolerant.

[dronus]

Seems I solved this. The newer OpenAL just seems to be a little bit slower on some of the GL10... calls. When playing mp3's, the buffers are ususally small, say 2048 bytes for example. So my app just missed to enqueue fast enough, and the buffer queue runs empty. When using 5 instead of 3 buffers, it works again.

Next days I'll do some profiling to find out which AL10 method is slow now. alGetSourcei() itself seems to take quite some time...