No sound under Linux + JRE 1.6 update 16

Hi Paul just a quick question, what happened with the changes to indirect buffers in lwjgl 2.3?

2.3

* new: Removed support for indirect buffers as arguments to AL/GL functions

does the new version works with the newer versions of lwjgl?

rubén

My thought was to use what you have as a second step to check after locating the Java Sound Audio Engine mixer if it turned out to have no target lines. This would almost never happen (you are the first to report this problem in fact), so for everyone else the code would still select the Java Sound Audio Engine as before.

[quote=“gouessej,post:20,topic:35502”]
That’s a good idea – after trying Java Sound Audio Engine first, it would be nice to chose the second option with some degree of intelligence. What parameters should go into determining such a score, though? Certainly the ability to use target lines first. I’ll check if there are other things to test for like compatibility with pitch/pan/gain controls, etc.

[quote=“gouessej,post:20,topic:35502”]
What would be the purpose of more than one mixer at a time? Or do you mean something else?

[quote=“ruben01,post:21,topic:35502”]
Yes it does.

As far as I know, it is reproducible only with Linux if the webcam is plugged before booting. It would be fine if you could confirm that “my” fix is useless with Windows and a webcam.

Maybe a cleaner solution would consist in calling getTargetLineInfo, checking if any Line.Info is an instance of Port.Info and then checking if there is at least one valid target port. I will check it at home later.

[quote=“paulscode,post:22,topic:35502”]
It would be fine for the programmer not to have to choose manually the mixer when an audio format is not supported by Java Sound Audio Engine but it is supported by any direct audio device. Moreover, it is easier to associate a “score” to a mixer when you know which audio format you have to support.

Do you know JASS?
http://www.cs.ubc.ca/~kvdoel/jass/

Personally I will investigate a bit more and it is highly probable that I will write a bug report.

Edit.: my “fix” is not correct because the Java Sound Audio Engine has no target line info even though it works fine. I have to find something else.

Maybe we should give a look at this :
http://quentinc.net/java/soundapi.php

Looks like basically the same thing I’ve done with SoundSystem + LibraryJavaSound plug-in + various Codec plug-ins. Obviously I’m not the only programmer out there who has written a pure-java alternative for 3D sound… Feel free to give it a shot and let me know how well it works. I don’t think I would use it personally, just because it is licensed by LGPL (better than GPL but still designed by total control freaks IMHO).

You’re right, I’m a bit disappointed, it does less than your APIs, it has nothing to do with the license. Someone advised me to give it a try, I did.

I have to write another fix for my problem and a bug report concerning JSAE using the microphone instead of my sound card.

The fix is there:
http://www.java-gaming.org/index.php/topic,16094.msg187961.html#msg187961

This looks to be based on a major logic error to me. The first bit of logic seems correct - if the webcam is the first Mixer.Info in the list, it is probably also the device referred to by “Java Sound Audio Engine” (seems to be the case based on the Java Sound bug). However, it seems to me that your fix would arbitrarily chose the first Mixer that doesn’t have the words “Camera” or “Java Sound Audio Engine” in the name. While this may work for your test machines, I suspect there are system configurations out there on which this fix would not work. Consider the following hypothetical device list:

Cool Web Camera
Java Sound Audio Engine
USB Microphone
Intel ICHx AC97 Soundcard

Wouldn’t it be better to chose the first device for which mixer.getTargetLineInfo().length>0? Like so:

    if( infos.length>0 && infos[0].getName().contains( "Camera" ) )
    {
        Mixer mixer;
        for( int i=1; i<infos.length; i++ )
        {
            mixer=AudioSystem.getMixer( infos[i] );
            if( !infos[i].getName().contains( "Camera" ) && !infos[i].getName().equals( "Java Sound Audio Engine" )
                && mixer.getTargetLineInfo().length>0 )
            {
                LibraryJavaSound.setMixer(mixer);
                break;
             }
         }
    }
...

For that matter, couldn’t the if statement get rid of the name checks and use only the TargetLineInfo length check? Or was there a reason you changed to this method?

mixer.getTargetLineInfo() returns 0 even though Java Sound Audio Engine is able to work correctly. The second version of the fix uses JSAE when possible and uses another mixer only when JSAE would not work correctly whereas the first version of the fix always skips JSAE even in cases we could rely on it. You’re right, I might implement a stronger test to choose a better mixer.

Ah, I see.

[quote=“gouessej,post:29,topic:35502”]
I’m thinking the best solution will be to try and create a SourceDataLine for each chosen Mixer, and check for compatibility based on static parameters that the user can change to fit their needs (things like range of sample-rates, required controls, etc). If none of the available Mixers are able to meet those parameters, the thrown SoundSystemException should indicate what the specific problem was. I’ll start working on this concept when I get home this evening, and when its implemented, maybe I can have you beta-test it for me to make sure it works in your particular case.

It is a good idea, I agree with your conclusion. We should call Mixer.isLineSupported() with some very basic SourceDataLine instances using very common audio formats that should be supported even by the poorest implementation of Java Sound. Skipping explicitly the camera and JSAE in my case is still a useful step because when JSAE should not be used, isLineSupported returns true even though you use the audio format of a sample it is not able to play :frowning:

[quote=“gouessej,post:31,topic:35502”]
In this case, do you know if the exception is thrown before the start() method is called? If it happens when the SourceDataLine/Clip is created or buffer is attached, it would be possible for me to create a test line to reveal the problem and handle it in my code. But if it doesn’t happen until start() is called (or if no exception is thrown at all), I’m not sure of a better workaround than the one you are using.

I remember that the attachment fails, it says “attachBuffer returns null” or something like that. I will send you the trace in 8 hours when I’m back home. I remember that there are already a lot of worrying messages displayed when creating a SoundSystem instance far before playing any sample.

[quote=“gouessej,post:33,topic:35502”]
Excellent, then I should be able to test for the problem within the LibraryJavaSound plug-in, so you won’t need that bug-fix any more.

It is really fine but I will have to write a bug report concerning the fact that Java Sound Audio Engine tries to use my microphone instead of using my sound card with a small test case (get the mixer, get a clip from it, play a basic sound). Can you provide me a very basic AU file?

The stack trace is below:

[quote=“gouessej,post:35,topic:35502”]
Here, I converted one of the test sounds I use a lot for testing purposes:
test.au

Thanks.

I get this even though it works with my fix:

[quote]Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
Buffer null in method ‘attachBuffer’
Error in class ‘ChannelJava Sound’
AudioFormat null in method ‘resetStream’
Error in class ‘ChannelJava Sound’
AudioFormat null in method ‘resetStream’
Error in class ‘ChannelJava Sound’
AudioFormat null in method ‘resetStream’
Error in class ‘ChannelJava Sound’
AudioFormat null in method ‘resetStream’
Error in class ‘ChannelJava Sound’
Pan control not supported
Error in class ‘ChannelJava Sound’
Sample rate control not supported
[/quote]

The first message about sample rate isn’t much of a problem (unless you want to change the pitch or use the new Doppler effect).

The second message is somewhat problematic - 3D sound will not really be “3D” without a Pan control (volume differences between left and right speaker).

The other two messages are caused by a logic error in my code (I had assumed that all the channels are associated with sources, which of course rarely ever the case). This shouldn’t effect functionality, just generate the annoying messages. I’ll have this fixed in the next release.