Linux sound choppiness

[elias4444]

I couldn't find any other posts on this after several searches (although I'm pretty sure I've posted about it before), so here goes another...

I've noticed that sound on Linux is often choppy. I've tried several other games besides my own (Tribal Trouble, Titan Attacks, etc) and noticed that the problem persists. I only have the one linux box, so it could just be the sound chip/driver, but wouldn't mind hearing from some other Linux testers if they have the same problems or not. It's most evident in streamed audio (e.g., background music). Sometimes it takes a little bit to start happening (usually not longer than a minute though).

[bobjob]

i dont run on linux, but i recently added sounds support. can you please test my app, and tell me if the sound is choppy (on linux)
http://users.on.net/~bobjob/TD.jnlp

i get choppy music on tribal trouble (music in winXP) i think its due to a sources issue.

[elias4444]

Sorry it took me a while, my linux machine is actually my wife's laptop (that runs Vista, which I can't stand, so I dual boot Linux on it for me).

I'm getting an error when I try to launch your game though:

Error 101: org.lwjgl.LWJGLException: Could not switch mode

[bobjob]

sweet thanx man, i just learned that linux has 24 bpp, not 32. i think thats why.

[ryanm]

I'm experiencing sound choppiness on linux, and it's very annoying. For example, if I play this sample of white noise, using the PlayTest class bundled with lwjgl, this is what I hear.
Playing the bundled center.wav sample results in this output.
I'm running the latest kubuntu release, and it all works fine in Windows

Has anyone else experienced this?

edit: Just tested with joal, the webstart demo here works fine.

[oak]

I have the exact same problem (using LWJGL through JME). And I seem to have found a solution:

Instead of creating the ALContext with: AL.create(), you should use AL.create(null, -1, -1, false); to let the implementation it self choose its values. This default-behavior was changed a few revisions ago because "it gave strange results". I would therefor advice that you only do this in cases where you have to (folks using Linux) - at least that is what I intend on doing.

There still seems to be minor clicks in the sound after this, but they might as well come from streaming-underrun and such as they are subtle and infrequent.

[Matzon]

you could also try and use opeanl-soft, to see if its backend related:
http://kcat.strangesoft.net/openal.html

We are considering switching to this library instead, but there are some size issues.

[ryanm]

I have the exact same problem (using LWJGL through JME). And I seem to have found a solution:

Instead of creating the ALContext with: AL.create(), you should use AL.create(null, -1, -1, false); to let the implementation it self choose its values. This default-behavior was changed a few revisions ago because "it gave strange results". I would therefor advice that you only do this in cases where you have to (folks using Linux) - at least that is what I intend on doing.

There still seems to be minor clicks in the sound after this, but they might as well come from streaming-underrun and such as they are subtle and infrequent.

Doesn't appear to help in my case I'm afraid.

<looks at openal-soft> does anyone feel charitable enough to whip up an lwjgl library from this? I, frankly, have neither the fortitude nor the skill

edit: I thought it worked a bit at first, closer examination show this not to be the case

[oak]

testing some more I also find that this did not really do any difference - I must just have become so used to the messed up sound that I thought it was ok. I guess we will have to look at other sound solutions for now - trying to figure out what goes wrong is not feasible since we can live without 3D sound in our game - for now.

[oak]

Well, it seems that fixing OpenAL is the shortest path. I have found that:

AL.create(null, -1, -1, false);

gives better results than AL.create(), this led me to:

AL.create(null, 44100, 1, false);

Which gives quite fine results, except now it is clear wherein the problem lie, its the update-frequency (or the actual update) since the last one specify an update frequency of 1hz, the clicks/discontinuities happen only 1/second, giving almost nice sound and at least showing where the problem could be.

I will dive further into this tonight, at least give it an hour or two more.

[oak]

Ok, I could not figure out what was wrong with openal in LWJGL, until I realized that the "libopenal.so" is not even built with LWJGL - it is just a binary file.

Then I downloaded openal-soft, built it with cmake and now I have the most crystal clear perfect sound coming out of my speakers, HURRAY!!!

I can only suggest that you build and bundle LWJGL with this openal-soft for linux users. For testing I have placed my binary library here:

http://emanuelgreisen.dk/stuff/libopenal.so

The openal-soft is released under LGPL so I think there should be no issue bundling a binary with LWJGL.

Have fun!

[oak]

Playing a little around with openAL-soft I find that the device-list is an array of char* but with:

ALC10.alcGetString(device, ALC10.ALC_DEFAULT_DEVICE_SPECIFIER)

Only the first element is extracted. This is very sad, since this list could be useful when allowing a user to chose what sound-device to use. For now I just print the list as it is built by OpenAL-soft to stderr, this is a hack but it gives an idea what devices are available. The output is something like this:

New Device: ALSA Software on default
New Device: ALSA Software on HDA Intel
New Device: OSS Software
New Device: Wave File Writer

The modified library can be downloaded here: http://emanuelgreisen.dk/stuff/libopenal.so

[Matzon]

this is an issue that I seem to have fixed or made an alternate method for at some point...
the problem is that they hacked the device string to be:
device1\0\0device2\0\0device3\0
and since a string by definition is null terminated, passing this to Java yields: device1

I'll see what I can do about it

[oak]

Looking at some code-snippets around on the web, I find that this is how OpenAL does things.

Here is one place where they "chop it up":

http://opensource.creative.com/pipermail/openal/2005-December/009141.html

In OpenAL-soft the container for the soundcards is defined as:

static ALCchar alcDeviceList[2048];

I guess the easiest would be to add an other helper method to ALC10.java (and native) like this:

public static String[] alcGetStringv(device, int enum);

Where the native method would do the magic, double-\0 terminated string-array split-up. This method could then later be used in conjunction with alcGetString(device, enum) returning these strange string-array representations in the future.

[Matzon]

aye - but I already made somekind of solution for it - I just need to find it again Must have been remvoed during a commit or something