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…
True, but there are several pure-java 3D graphics engines out there. The one I use (really good, and has a version for Android) is jPCT.
[quote=“paulscode,post:40,topic:37148”]
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.
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.
True, just depends on the app. I do a lot of both myself, but I’ll probably have to start going OpenAL more often, in light of this new information. Such a shame…
I’m back in civilisation. 
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.
[quote=“paulscode,post:28,topic:37148”]
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 :clue: 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.
@gouessej
I 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 already use Audacity. I admit you’re right about the low need of supporting completely different formats at the same time.
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.
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 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 said this earlier, but you said it better! ;D 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!
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/
[quote=“nsigma,post:50,topic:37148”]
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.
[quote=“paulscode,post:51,topic:37148”]
You sum up what I meant. You reassure me, my English is not that bad ;D 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.
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… :’(
[quote=“nsigma,post:50,topic:37148”]
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.
[quote=“nsigma,post:50,topic:37148”]
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?
Yes I found a few machines whose mixer supports it but only mono or supports it fine but with a few lines :s
Of course not, but as in this case it’s almost certain that the system is the problem then it’s already screwed up!
gouessej, can you post the output of
cat /proc/asound/cards
when you get this issue - prove one way or another whether it’s an ALSA indexing problem.
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.
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
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!
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.
I will do it when I’m at home.
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! ;D )
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.
Interesting idea on reading what’s in ~/pulse. I’ll look into this…
[quote=“nsigma,post:46,topic:37148”]
Same issue as with everything else - I can only get sound as long as nothing else is using audio.
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. 
[quote=“nsigma,post:46,topic:37148”]
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.
[quote=“nsigma,post:46,topic:37148”]
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.
;D 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.
[quote=“Socob,post:58,topic:37148”]
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!
Fair enough, even if I don’t find the limitations very workable. ;D
[quote=“nsigma,post:59,topic:37148”]
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.