@gouessej:I actually have the Oracle JVM set as default for testing. I was right, however - Praxis was (for some reason) still started with OpenJDK. With the Oracle JVM, I have the same issues as before (no sound even with Praxis). So I guess I'm back at the start.

@paulscode:Nice to have you in this thread! Your library is great (and works fine as long as I avoid JavaSound )! I'm curious, have you ever had reports of similar issues on Linux with current versions of your library, or am I the only one having these kinds of problems with JavaSound?

The best solution is to do software mixing on a single line, as you've pointed out.

My problem with this is that I can't even get a single line on my computer with the Oracle JVM and Linux! Well, I can, but it doesn't do anything if anything is already playing sound. All of the available output mixers (cf. first post) on my machine are affected by this. I mean, I would consider doing software mixing, but before that, I need to be able to output sound at all.

OpenJDK really should ship with its own native software mixer, like the Java Sound Audio Engine.

Now, this is the thing: I don't actually have any problems with sound on Linux with OpenJDK (except that methods like DataLine.stop() or DataLine.drain() take ages to return for some reason). This is because OpenJDK provides additional mixers (like the "default" mixer and the "PulseAudio" mixer). However, even with the Oracle JVM (version 6 update 26), the "Java Sound Audio Engine" mixer is not available on my machine. This only leaves me with what I assume to be mixers with direct access to the soundcard, so if I use those, I either lock up the soundcard or it is already locked, both of which is undesirable. Do you perhaps have any clue why I don't have the "Java Sound Audio Engine" or how I could get away without using it?

I'm curious, have you ever had reports of similar issues on Linux with current versions of your library, or am I the only one having these kinds of problems with JavaSound?

My own netbook (which is the only computer I have access to until I get back from this deployment) also has the "no software mixers" issue. However, unlike your situation, one of the hardware mixers does have a line available for output. Yours is the first situation I've heard of where none of the available mixers have any lines available for output.

Do you perhaps have any clue why I don't have the "Java Sound Audio Engine" or how I could get away without using it?

Now that does seem very odd. I'm pretty sure the official Sun Java for Linux came with the Java Sound Audio Engine in the past, although I haven't played around with any of the recent versions in quite a while (I kind of gave up on Linux mixers a while back and have been focusing on developing a usable software mixer of my own instead). In your situation, it doesn't seem possible to not use the Java Sound Audio Engine, if there are no usable alternative mixers available. I think the first question to try and answer is why it is missing in the first place. I'll look into this to see if Java Sound Audio Engine is available on my netbook with the latest version of Oracle Java or not (I'm using OpenJDK at the moment).

Now, this is the thing: I don't actually have any problems with sound on Linux with OpenJDK (except that methods like DataLine.stop() or DataLine.drain() take ages to return for some reason). This is because OpenJDK provides additional mixers (like the "default" mixer and the "PulseAudio" mixer).

Are those mixers recent additions? I don't recall those being available in the past (it has been a while since I worked on this though). I guess even if they are a recent addition, you can't really count on your target audience to have them depending on what version of OpenJDK they're running.

We love death. The US loves life. That is the difference between us. -Osama bin Laden, mass murderer

Java Sound Audio Engine is not available on my netbook either for the recent version of Oracle Java. That's really odd - I'm almost positive that it was available on previous versions. I wonder if they officially did away with it or something? In my case, I do have two mixers available with 32 lines, plus two with zero lines.

Socob, could you link with the following version of the plug-in instead (it prints a little more information to the console than the previous version):LibraryJavaSound plug-in

The test should be simple to run - just instantiate the SoundSystem and grab what gets printed to the console. Alternately, you can run the following applet and grab the console output (it'll be a bit messier, but should have all the same info in there as well):Bullet / Target Collision Applet

gouessej, could you also run either of the above and post the output? Looking at the code, you may have multiple lines available on your mixer like I do, regardless of the fact that only the first sound played correctly. I'll have to verify that with the output, though. If so, then my upcoming release of the LibraryJavaSound plug-in should fix your problem. Socob's problem is going to be more difficult to solve.

We love death. The US loves life. That is the difference between us. -Osama bin Laden, mass murderer

Are those mixers recent additions? I don't recall those being available in the past (it has been a while since I worked on this though). I guess even if they are a recent addition, you can't really count on your target audience to have them depending on what version of OpenJDK they're running.

I have no idea how recent they are, but a link I've brought up earlier in this thread suggests that they're at least fairly recent. Even if it is a hindrance, I think it's fair to tell users to update their JRE version. At least it's better than having to tell them to specifically use either an Oracle JRE or OpenJDK, which is what I've been dealing with so far.

Anyway, thank you for posting a test. I'm using Linux Mint 11 32bit with the Oracle JVM 1.6 update 26. First, I tried the Bullet/Target Collision applet with nothing else running (i.e. no Flash or anything) and got sound:

Note that the "NVidia" mixers seem to be related to my soundcard (it's an onboard soundcard). "NVidia [plughw:0,0]" is able to play sound from my speakers, but as you can see, if sound is already running, the maxmimum number of lines is zero. I have no idea what "NVidia [plughw:0,1]" is, but I can't hear anything when that's used.

The mixer called "Generic" is the HDMI port of my graphics card, so I wouldn't want to use that.

Also, I seem to have the same problem that I can only hear the first sound (even in the first test). After I shoot the second laser in the applet, I get this on every shot:

Thanks for the detailed explanations. Is there only one program (you mentioned Flash video) that causes the problem, or is it caused by anything that plays sound? Once the offending program(s) are shut down, does sound start working again, or do you have to reboot to get sound back?

Also, for clarification, when NVidia [plughw:0,1] was used, you didn't even hear the first sound play, correct?

About the first sound playing and not the subsequent sounds - interestingly, it used to be reversed (this used to affect OpenJDK sometimes but not Sun Java - although I think that was because Sun Java used to reliably have the Java Sound Audio Engine.. doesn't seem to be the case any more). I'm getting the same thing on my netbook with the recent version of Oracle Java. What causes this is that you have a maximum number of lines, after which no more can be created. That's all well and good, but for some reason, some of the time (depending on Java version and hardware apparently), even if you shut down and discard one of the lines, you still can not create any more (throws an error on dataLine.open). Because of the way the SoundSystem currently works, each new source you create with a new audio format must shut down one of the lines to create a new one (because I could not find any way with the API to change the audio format of an existing line - point me in the right direction if anyone knows of a way, please). So depending on how many lines were created in the ranking system, you end up with a limited number of lines left to play sounds on (resulting in the behavior of the first sound playing, then no subsequent sounds). I'm improving the way the line management and ranking works, and as long as you use all files of the same audio format, that problem should be gone from the next release of LibraryJavaSound.

All that being said, this will only help you if Flash, etc. are not playing. I'll have to think about this one some more..

We love death. The US loves life. That is the difference between us. -Osama bin Laden, mass murderer

Is there only one program (you mentioned Flash video) that causes the problem, or is it caused by anything that plays sound? Once the offending program(s) are shut down, does sound start working again, or do you have to reboot to get sound back?

As far as I can tell, everything that plays sound causes the problem. I tried a few more programs, and so far, I haven't found anything that didn't cause it. Sound does start working again once I close all of the offending programs, so I don't have to reboot.

All that being said, this will only help you if Flash, etc. are not playing. I'll have to think about this one some more..

I don't know how much (if any) of this changed with Java 1.7, but so far, it does look like JavaSound really is impossible to use reliably on Linux, especially now that the "Java Sound Audio Engine" seems to be gone on some machines for some reason. I guess the only way to solve this at all would be to open a bug report on Java development or something (again, as long as this still happens with Java 1.7)? I really don't see any other way as long as you can't even get the most basic sound output.

I don't know how much (if any) of this changed with Java 1.7, but so far, it does look like JavaSound really is impossible to use reliably on Linux, especially now that the "Java Sound Audio Engine" seems to be gone on some machines for some reason. I guess the only way to solve this at all would be to open a bug report on Java development or something (again, as long as this still happens with Java 1.7)? I really don't see any other way as long as you can't even get the most basic sound output.

I have already submitted several reports including one about sound on Linux and it might be never fixed. I'm sorry to say that but I'm forced to switch to OpenAL and I advise you to do so.

That isn't the system that had the problem with playing only the first sound one time, is it? It seems to have the Java Sound Audio Engine, which doesn't have that problem.

In fact, it is. I use 2 JVMs on this machine (at home), it works fine with Oracle JVM as you see but not with OpenJDK.

Rgr, problem with OpenJDK, not with Oracle JVM (that was historically the case, although now I'm forced to conclude that at some point in a recent version, Oracle has shot themselves in the foot by making their closed-source product less compatible on Linux by removing the Java Sound Audio Engine and not providing an alternative software mixer).

I don't know how much (if any) of this changed with Java 1.7, but so far, it does look like JavaSound really is impossible to use reliably on Linux, especially now that the "Java Sound Audio Engine" seems to be gone on some machines for some reason.

That's kind of where I'm at in the thought process as well. If you had even a single line that you could reliably play on, then mixing would be possible, but without that I really can't think of what alternative there is. Fingers crossed they fix at least one of those issues in the next release of Java.

I have already submitted several reports including one about sound on Linux and it might be never fixed. I'm sorry to say that but I'm forced to switch to OpenAL and I advise you to do so.

This really vexes me, because I write applets almost exclusively. I know from experience that a lot of people simply will not accept a security exception on a web page (especially when the warning recommends that they don't). A pure-Java option for 3D audio is absolutely critical.

I suppose one could just warn the user that if they are experiencing issues with no audio, to ensure that no other program is playing audio while the application is starting up. That would give the sound system a chance to grab an available line (and not ever close it until the application shuts down). Only problem with that idea is that although the application would now have sound, nothing else would (so the user would be out of luck if they wanted to listen to mp3's or hear IM warning sounds for example, while they were running it)

We love death. The US loves life. That is the difference between us. -Osama bin Laden, mass murderer

This really vexes me, because I write applets almost exclusively. I know from experience that a lot of people simply will not accept a security exception on a web page (especially when the warning recommends that they don't). A pure-Java option for 3D audio is absolutely critical.

Sorry. I agree with you but we have to come down to Earth. When doing some 3D, you have to use third party libraries and then it is highly probable that you have to use signed JARs. A pure Java option for audio is really useful for 2D but for 3D, it is useful only for those who do not already use any binding of OpenGL. JOGL does not have a "magic" certificate anymore...

That's kind of where I'm at in the thought process as well. If you had even a single line that you could reliably play on, then mixing would be possible, but without that I really can't think of what alternative there is. Fingers crossed they fix at least one of those issues in the next release of Java.

I hope so, too, but from experience, I'm a little pessimistic about things like that. Either way, the current situation still is what it is.

@gouessej:It's just extremely annoying that you can't use applets without security warnings if you want sound at all. Sure, if you're working with 3D, the impact is "eased" a little because you're probably already using native libraries anyway, but that's not really an excuse.

So, at this point, I sort of ran out of things to say. It looks to me like we've pretty much reached a consensus on the situation - I guess there's just nothing we can do about it. The sad thing is that on Windows, all of this is trivial and works without issues. I suppose when it comes to JavaSound, I'll have to differentiate between users of different platforms after all (this is what I meant by JavaSound being non-portable). Then again, as Linux users tend to be more knowledgeable anyway, maybe they'll be more accepting and less confused by things like security exceptions. Still, the situation is far from desirable.

@gouessej:It's just extremely annoying that you can't use applets without security warnings if you want sound at all. Sure, if you're working with 3D, the impact is "eased" a little because you're probably already using native libraries anyway, but that's not really an excuse.

You can use a digitally signed certificate (not free of charge) to get a less scary warning. Then, you have to use it with all your JARs. The ancestor of my game was relying on software rendering in pure Java but it was so slow........ 1 frame every 2 seconds in full screen mode, unbearable. Using hardware acceleration and then native libraries is almost mandatory in 3D except if your scene is quite "small" or if you don't target low end machines.

I actually have the Oracle JVM set as default for testing. I was right, however - Praxis was (for some reason) still started with OpenJDK. With the Oracle JVM, I have the same issues as before (no sound even with Praxis). So I guess I'm back at the start.

Damn! Do you mean you get no sound full stop, or no sound if anything else is playing? You'll never be able to play sound with the Oracle JDK (at least on Java 6) while anything else is playing audio or grabbed the soundcard - remember that Java 6 predates a lot of the improvements made in this area on Linux. Hopefully Java 7 might have corrected some of this - I must check. It is also possible to install the pulseaudio mixers from OpenJDK on the Oracle JDK using the service provider mechanism, but not ideal for the average user!

Interesting bug that Praxis missed your default JDK setting. The launcher is from NetBeans as Praxis is NetBeans platform based - if it's ignoring this setting it would seem to be a bug in the launcher.

I understand all that, and I'm not trying to suggest everyone become an audio specialist (although I don't believe for a minute you'd really find software mixing hard considering what else you've done - it's basically summing arrays of data).

The best solution is to do software mixing on a single line, as you've pointed out. Unfortunately, there is a little more to it than your characterization if you need to support pitch changes, panning, and mixing multiple formats. Sure, all those can be done as well, but then you also have to get it to run at an acceptable speed to avoid latency. Doing the mixing in native rather than pure java is really the way this should be done.. OpenJDK really should ship with its own native software mixer, like the Java Sound Audio Engine.

Java is quite capable of doing all this without resorting to native code. I've been coding pure-Java audio DSP projects for 7 years, sometimes on hardware that was 10+ years old, and never had any performance issues doing far more complex things than we're talking about here. If you want to code in a slow scripting language that needs native code to do anything interesting, you should switch to Python!

Java is quite capable of doing all this without resorting to native code. I've been coding pure-Java audio DSP projects for 7 years, sometimes on hardware that was 10+ years old, and never had any performance issues doing far more complex things than we're talking about here. If you want to code in a slow scripting language that needs native code to do anything interesting, you should switch to Python!

It should be the case but we cannot wait for Oracle to fix bugs in the Linux-specific part of JavaSound. Come down to Earth, JavaSound tries to use my webcam to output sounds Of course, I would prefer a pure Java solution but it is not the way to go until some bugs are fixed. I agree with you about the fact that sound algorithms could be implemented in pure Java, I still think that a pure Java solution even now could be very useful but I need low latency, I want to be able to play very short sounds, sometimes several sounds at the same time, spatial sound... Therefore, I have to avoid using Clip... It means that in some projects, JavaSound can hardly be used. I won't modify all my samples to be sure that they measure at least 2 seconds in order to work around JavaSound limitations. If one day someone succeeds in writing a low latency mixer using a single line and able to play different samples using different formats at the same time, then I might reconsider my position.

@gouessejI would like to challenge you on your statement that you want a sound system that can handle many different formats at the same time. This seems like both a significant and needless waste. With a free tool like Audacity, all sounds can be given the same, "optimum" format.

We often go to great troubles to precalculate values so that we don't have to do the same calculation in a bit of working code. Why not treat audio data in the same way, taking responsibility to manage and optimize the data BEFORE it gets incorporated into the game?

I wouldn't recommend this, except that Audacity is free and easy to use. If the Mixer is only dealing with one format, it is going to operate a lot quicker and cleaner, and have a significantly smaller footprint. And, it will likely get built a lot sooner, too.

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

@gouessejI would like to challenge you on your statement that you want a sound system that can handle many different formats at the same time. This seems like both a significant and needless waste. With a free tool like Audacity, all sounds can be given the same, "optimum" format.

I already use Audacity. I admit you're right about the low need of supporting completely different formats at the same time.

We often go to great troubles to precalculate values so that we don't have to do the same calculation in a bit of working code. Why not treat audio data in the same way, taking responsibility to manage and optimize the data BEFORE it gets incorporated into the game?

I wouldn't recommend this, except that Audacity is free and easy to use. If the Mixer is only dealing with one format, it is going to operate a lot quicker and cleaner, and have a significantly smaller footprint. And, it will likely get built a lot sooner, too.

The problem is that JavaSound Audio Engine is not available everywhere. Therefore, when it is not there, you have to rely on other mixers which may support different sample rates, etc... I like your suggestion, I almost always do that but I don't want to spend a lot of time in tinkering source code about sound. With Paul Lamb Sound Library and OpenAL (JOAL), I just have to indicate if I want to use streaming or not for each sample and that's all. I already have to write (WYSIWYG FPS editor: JFPSM, mesh optimizers...) or deeply modify (Ardor3D, etc...) a lot of Java "tools" to work on my projects, I cannot decide to take the responsibility of managing everything from the OpenGL driver to the sound system.

Java is quite capable of doing all this without resorting to native code. I've been coding pure-Java audio DSP projects for 7 years, sometimes on hardware that was 10+ years old, and never had any performance issues doing far more complex things than we're talking about here. If you want to code in a slow scripting language that needs native code to do anything interesting, you should switch to Python!

It should be the case but we cannot wait for Oracle to fix bugs in the Linux-specific part of JavaSound. Come down to Earth, JavaSound tries to use my webcam to output sounds

Sorry, let me rephrase what I wrote - I've been coding pure-Java audio DSP projects professionally on Linux for 7 years. JavaSound has bugs for sure, but maybe you should actually come down to Earth and realise that not every bug you see has anything to do with Java. This webcam issue is probably a well known problem with ALSA, and the way it iterates soundcards - webcams will often end up at index 0. I've fixed this on a project myself in the past, and it took a few minutes to Google how - I've also suggested this to you in the past. You need to either blacklist the webcam audio driver (if you don't need the mic on it) or force the webcam not to be at index 0. Unfortunately, some distributions don't have a GUI to set this.

It could be that the software you're using is naively picking mixer 0, that ALSA is incorrectly reporting that the device supports output, or that the software is using the Java Sound Audio Mixer which AFAIK basically uses whatever ALSA has put at /dev/dsp (not a bug as such, just something that reflects how old that code is and the sooner it's gone the better!).

I agree with you about the fact that sound algorithms could be implemented in pure Java, I still think that a pure Java solution even now could be very useful but I need low latency, I want to be able to play very short sounds, sometimes several sounds at the same time, spatial sound... Therefore, I have to avoid using Clip... It means that in some projects, JavaSound can hardly be used. I won't modify all my samples to be sure that they measure at least 2 seconds in order to work around JavaSound limitations. If one day someone succeeds in writing a low latency mixer using a single line and able to play different samples using different formats at the same time, then I might reconsider my position.

I need to all the above and more too, and do. Clip is generally crap though! There are lots of low-latency Java audio libraries, though they're generally more complex than you require - I've mentioned quite a few of them earlier on this thread and elsewhere to you in the past! The Praxis libs will also do all you mention and more when I release them separately. However, I absolutely understand the need for something simpler and lightweight, which is why I'm glad Paul has started looking at a simple software mixer, and am happy to contribute anything I can.

@gouessejI would like to challenge you on your statement that you want a sound system that can handle many different formats at the same time. This seems like both a significant and needless waste. With a free tool like Audacity, all sounds can be given the same, "optimum" format.

We often go to great troubles to precalculate values so that we don't have to do the same calculation in a bit of working code. Why not treat audio data in the same way, taking responsibility to manage and optimize the data BEFORE it gets incorporated into the game?

I wouldn't recommend this, except that Audacity is free and easy to use. If the Mixer is only dealing with one format, it is going to operate a lot quicker and cleaner, and have a significantly smaller footprint. And, it will likely get built a lot sooner, too.

I said this earlier, but you said it better! Most people on here would not dream of shipping graphics assets at the wrong resolution and scaling them unnecessarily on the fly, but think that's a good thing to do with audio!? The one thing that might make sense is audio compression (mp3/ogg) for long backing tracks (not FX!), but we're talking out of the realm of pure JavaSound then anyway!

Therefore, when it is not there, you have to rely on other mixers which may support different sample rates, etc...

Have you actually found one that doesn't support CD quality audio (44.1kHz)?

Best wishes, Neil

PS. If it's of any interest - http://www.youtube.com/watch?v=YNe03b5BxLM - a video of an early piece I did for a museum in the UK about 5 years ago, and the one that I had to fix the webcam for! Apart from JMF for webcam input that's all pure Java - motion sensing controlling graphics and live multichannel audio DSP. The audio lib I was using at the time (though some of the components were mine) was JASS http://www.cs.ubc.ca/~kvdoel/jass/

JavaSound has bugs for sure, but maybe you should actually come down to Earth and realise that not every bug you see has anything to do with Java. This webcam issue is probably a well known problem with ALSA, and the way it iterates soundcards - webcams will often end up at index 0. I've fixed this on a project myself in the past, and it took a few minutes to Google how - I've also suggested this to you in the past. You need to either blacklist the webcam audio driver (if you don't need the mic on it) or force the webcam not to be at index 0. Unfortunately, some distributions don't have a GUI to set this.

From the perspective of an average amateur developer, we don't want to require the end user to have to screw around with their system (or brick it if they are dumb***'s). Whether the problems are Java's fault or not, the solutions we want need to be programmable into our own code. For example, this is why gouessej has switched to JOAL and AL-soft, due to the difficulty (and even incapability in the subject of this particular thread) to control various problems from his own code.

We love death. The US loves life. That is the difference between us. -Osama bin Laden, mass murderer

From the perspective of an average amateur developer, we don't want to require the end user to have to screw around with their system (or brick it if they are dumb***'s). Whether the problems are Java's fault or not, the solutions we want need to be programmable into our own code. For example, this is why gouessej has switched to JOAL and AL-soft, due to the difficulty (and even incapability in the subject of this particular thread) to control various problems from his own code.

You sum up what I meant. You reassure me, my English is not that bad I cannot ask a 7-year-old child who does not even know what an operating system is to tinker his Linux distro to blacklist his webcam. 60% of my players use Linux.

Sorry, let me rephrase what I wrote - I've been coding pure-Java audio DSP projects professionally on Linux for 7 years. JavaSound has bugs for sure, but maybe you should actually come down to Earth and realise that not every bug you see has anything to do with Java. This webcam issue is probably a well known problem with ALSA, and the way it iterates soundcards - webcams will often end up at index 0. I've fixed this on a project myself in the past, and it took a few minutes to Google how - I've also suggested this to you in the past. You need to either blacklist the webcam audio driver (if you don't need the mic on it) or force the webcam not to be at index 0. Unfortunately, some distributions don't have a GUI to set this.

It could be that the software you're using is naively picking mixer 0, that ALSA is incorrectly reporting that the device supports output, or that the software is using the Java Sound Audio Mixer which AFAIK basically uses whatever ALSA has put at /dev/dsp (not a bug as such, just something that reflects how old that code is and the sooner it's gone the better!).

Oracle validated my bug report, at least one Oracle engineer admitted this bugs comes from JavaSound. Other non-Java applications using sound were not affected. Maybe I was a bit too harsh. The problem is that Java Sound Audio Engine was using my webcam, I could not use Clip instances anymore, I had to switch to another mixer. At the beginning, the workaround seemed obvious but I had to modify my samples to convert them to mono (which is still simple). On some machines, some sample rates were too high for the mixer I chose or a particular mixer supported the good sample rate but only a very few simultaneous lines...

I need to all the above and more too, and do. Clip is generally crap though! There are lots of low-latency Java audio libraries, though they're generally more complex than you require - I've mentioned quite a few of them earlier on this thread and elsewhere to you in the past! The Praxis libs will also do all you mention and more when I release them separately. However, I absolutely understand the need for something simpler and lightweight, which is why I'm glad Paul has started looking at a simple software mixer, and am happy to contribute anything I can.

I don't mind the weight as my levels are becoming more and more fat unlike me

I refuse using solutions relying on JNA which de facto excludes one of your suggestions. Yes you see what I mean, I just need something simple to play some samples in a 3D game, some musics while loading the arenas.

I said this earlier, but you said it better! Most people on here would not dream of shipping graphics assets at the wrong resolution and scaling them unnecessarily on the fly, but think that's a good thing to do with audio!? The one thing that might make sense is audio compression (mp3/ogg) for long backing tracks (not FX!), but we're talking out of the realm of pure JavaSound then anyway!

I can use Audacity even to modify "long" samples, musics, etc... I try to ship my samples in a single format, stereo, 44.1kHz, only .ogg files. What's wrong with that?

Whether the problems are Java's fault or not, the solutions we want need to be programmable into our own code.

You can already - provide a GUI to allow the user to select their soundcard (and use software mixing to account for the single output lines on most ALSA cards). Most Linux distributions unfortunately don't provide a GUI for selecting ALSA soundcard order. It might also be possible to ship the PulseAudio mixer from OpenJDK - it can definitely be installed into the Oracle JDK.

You sum up what I meant. You reassure me, my English is not that bad I cannot ask a 7-year-old child who does not even know what an operating system is to tinker his Linux distro to blacklist his webcam. 60% of my players use Linux.

No, of course not. You provide a GUI to provide a workaround. It doesn't stop this being a distro / ALSA problem though! Check first bit on Troubleshooting here for instance - http://wiki.debian.org/ALSA

Oracle validated my bug report, at least one Oracle engineer admitted this bugs comes from JavaSound. Other non-Java applications using sound were not affected. Maybe I was a bit too harsh.

Lots of other things that use older OSS or ALSA APIs could be affected by this, if it is an indexing issue - see previous post. I would assume that Oracle will get rid of Java Sound Audio Mixer entirely (it's closed source, 3rd party and uses the dated OSS bindings AFAIK), and bring in the stuff from OpenJDK - anyone know if they have in 7? Not that that helps us all on 6 for now!

I don't mind the weight as my levels are becoming more and more fat unlike me

I refuse using solutions relying on JNA which de facto excludes one of your suggestions. Yes you see what I mean, I just need something simple to play some samples in a 3D game, some musics while loading the arenas.

Huh? Nothing I've suggested uses JNA - they're all pure Java. I have written a JNA binding to JACK, but this has nothing to do with JavaSound or any suggestions I've made here. Not that I see why you're so vehemently opposed to JNA - it's pretty much JNI comparable speed these days.

Whether the problems are Java's fault or not, the solutions we want need to be programmable into our own code.

You can already - provide a GUI to allow the user to select their soundcard (and use software mixing to account for the single output lines on most ALSA cards). Most Linux distributions unfortunately don't provide a GUI for selecting ALSA soundcard order. It might also be possible to ship the PulseAudio mixer from OpenJDK - it can definitely be installed into the Oracle JDK.

In my humble opinion, the final user should not have to select the sound card even in a GUI. Your suggestion is better than using command line but when I play with a game, I don't expect from having to do such things.

In my humble opinion, the final user should not have to select the sound card even in a GUI. Your suggestion is better than using command line but when I play with a game, I don't expect from having to do such things.

We're talking about a minority situation where -

a) the user has more than 1 soundcard (or a webcam that has grand ambitions to be a soundcard! )b) the first (and usually default) soundcard picked up by ALSA is the wrong one.

In this scenario, the user will already have had to choose the soundcard in the OS's GUI (or the right one was selected because the wrong one wasn't plugged in at install time). Only then will they have to override your default mixer selection, and bear in mind there are other scenarios where they may wish to select another card (USB headphones, etc.)

The main issue is that most distros do not provide a GUI for doing this with ALSA, only with PulseAudio. Any software that bypasses PulseAudio then seems to be ignoring the user settings.

I wonder if there's another solution here (without involving native code), though it would involve file access. The default soundcard for PulseAudio is stored in ~/.pulse - it might be possible to parse the relevant file and find the right ALSA mixer through JavaSound.

You'll never be able to play sound with the Oracle JDK (at least on Java 6) while anything else is playing audio or grabbed the soundcard - remember that Java 6 predates a lot of the improvements made in this area on Linux.

Again, this is what I was talking about - if I can't even play sound at all as long as the soundcard is used, JavaSound is worthless to me. I would be okay with having a GUI for the user to select the correct audio mixer, but telling them to close everything that could even remotely involve sound (even if there is no sound actually playing, as in the case of Flash) is unacceptable. I appreciate javaSound and see why you would defend it, but as long as you can't solve this seemingly simple problem, you're not going to convince me of JavaSound.

I'm also still secretly hoping that things have changed with Java 7, but until that starts hitting the standard repositories (those of Debian/Ubuntu/Linux Mint in my case), there's no point for me to try anything.

Java is quite capable of doing all this without resorting to native code. I've been coding pure-Java audio DSP projects for 7 years, sometimes on hardware that was 10+ years old, and never had any performance issues doing far more complex things than we're talking about here.

That may be true, and I don't doubt what you're saying. However, the fact that it can be done doesn't mean it can be done easily or without restrictions.

You'll never be able to play sound with the Oracle JDK (at least on Java 6) while anything else is playing audio or grabbed the soundcard - remember that Java 6 predates a lot of the improvements made in this area on Linux.

Again, this is what I was talking about - if I can't even play sound at all as long as the soundcard is used, JavaSound is worthless to me. I would be okay with having a GUI for the user to select the correct audio mixer, but telling them to close everything that could even remotely involve sound (even if there is no sound actually playing, as in the case of Flash) is unacceptable. I appreciate javaSound and see why you would defend it, but as long as you can't solve this seemingly simple problem, you're not going to convince me of JavaSound.

I'm not trying to "defend" anything, definitely not JavaSound, just pointing out its limitations (some of which stem from the underlying system) and how to work with them. I was making the point that I'd rather see DSP / mixing happening in Java because it's fast enough, cross-platform and easier to modify - the less native code the better. That doesn't take away the fact that you need native code to write to the soundcard driver itself, and if you can't accept the limitations of what's included (either no mixing with other apps or specifying OpenJDK) then you're going to have to ship your own native code, which means a signed applet.

I can't remember you specifying you needed multiple applications to play audio at the same time initially, otherwise I'd have made this point a bit stronger earlier.

I'm also still secretly hoping that things have changed with Java 7, but until that starts hitting the standard repositories (those of Debian/Ubuntu/Linux Mint in my case), there's no point for me to try anything.

What I read yesterday would suggest the "default" ALSA mixer in OpenJDK came from Sun's original Java 7 code drop, which means this should be fixed. Still need to find the time to check for certain though!

I can't remember you specifying you needed multiple applications to play audio at the same time initially, otherwise I'd have made this point a bit stronger earlier.

Uh, well, I didn't even think of mentioning that. I've never heard of a game or even any application that needs exclusive access to the soundcard, especially not in 2011. "Can play audio with multiple applications" just isn't something that I'd put on a feature list; rather, I'd take it for granted.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org