I'm having problems getting sound to work with my java game. (I'm not using the lwjgl b/c I didn't know about it when I started, but I'm definitely going to use it for my next project )

When I run the game in Eclipse, everything works how it's supposed to, but when I compile into a runnable jar, sound doesn't play. I also would like help making it loop, but the important part right now is that I get it working

here is the current code I'm using, I create a new musicPlayer class at the beginning then call playMusic when I want to play a song and give it the file location in my project (ex: playMusic(music/Title.au); )

I would rather use getResourceAsStream. I think ra4king is right, maybe there is a path problem. If you really plan to write a music player, don't use plain JavaSound except for pedagogical interests as this API has some important limitations and bugs on some platforms. I used it for several years and I gave up when I noticed that on some machines, I couldn't even play the same sample twice... I use OpenAL through JOAL in Paul Lamb's Sound Library.

If you really plan to write a music player, don't use plain JavaSound except for pedagogical interests as this API has some important limitations and bugs on some platforms. I used it for several years and I gave up when I noticed that on some machines, I couldn't even play the same sample twice... I use OpenAL through JOAL in Paul Lamb's Sound Library.

Not this again. I have yet to see you post a single example of something that is actually a bug. A few things that would be welcome RFE's maybe. JavaSound is quite usable and reliable across platforms if you actually work within the constraints of what's queryable from the API, and as Paul mentioned in the Simple Line Mixer thread, when he took mine and other's advice to look at software mixing the performance is much better! OpenAL is not an option for anyone who doesn't want to ship native code.

@TheChibiNinja - not that you're actually using the JavaSound API. You should look at javax.sound.sampled.* not sun.audio.* - the 90's want their code back!

Not this again. I have yet to see you post a single example of something that is actually a bug. A few things that would be welcome RFE's maybe. JavaSound is quite usable and reliable across platforms if you actually work within the constraints of what's queryable from the API, and as Paul mentioned in the Simple Line Mixer thread, when he took mine and other's advice to look at software mixing the performance is much better! OpenAL is not an option for anyone who doesn't want to ship native code.

Are you laughing at me? The ability of playing the same sample twice would be welcome as a RFE The ability of playing any sample without having to plug-off the webcam would be welcome as a RFE NO! I already wrote some bug reports, none of these bugs have been fixed. OpenAL is THE option for anyone who wants cross-platform reliable sound support without being an expert of JavaSound and there is OpenALSoft if you don't like hardware implementation. I cannot spend my time in fixing bugs in the tools I use. TheChibiNinja has never mentioned that he doesn't want to ship native code. Simple Line Mixer is fine and enough for an music player but in more complicated applications including games. As TheChibiNinja wants to make a music player, your suggestion is fine but mine is not silly. I used JavaSound for several years and you cannot blame me for telling people that this API has some severe limitations and bugs preventing it from being used naively (without using a software mixer, by using Clip, etc...) in cross-platform games working both with Oracle JVM and OpenJDK. Even Minecraft uses OpenAL (but through LWJGL).

The ability of playing any sample without having to plug-off the webcam would be welcome as a RFE NO!

I've told you multiple times, this is not a bug in JavaSound. It is a problem with the way ALSA is indexing cards on your setup. It's not specific to Java, though it probably crops up as an issue now most commonly with Java, and I've previously posted link(s) to bug reports about this on various distros. A valid RFE would be for Java to use ALSA's default virtual device, as well as the direct hardware devices, which I think might be the case in JDK7, and is on OpenJDK.

Ok let's not continue with this OpenAL vs. JavaSound argument. JavaSound does have bugs and I have seen a couple of them, however it is perfectly usable.

It isn't. Clip should work, the same sample should be playable several times even on the OpenJDK but it is not the case. SDL uses ALSA on my machine as far as I know and only Java requires to pug-off the webcam. Therefore, nsigma is wrong. If you have to ask many Linux users to install Oracle JDK instead of OpenJDK, it does not mean that JavaSound is perfectly usable. If JavaSound could just do the stuff, I would have never panned to switch to OpenAL. We should not have to avoid using several high level classes of JavaSound because of their bugs. I don't play the "native" card, I would prefer a pure Java solution.

SDL uses ALSA on my machine as far as I know and only Java requires to pug-off the webcam. Therefore, nsigma is wrong.

Unless your symptoms have changed from the first time you posted about this - ie. sound fails when webcam is plugged in at boot, but not otherwise - then this is an ALSA indexing problem. Try googling it for a start - one of many, many forum posts and bug reports - http://forums.debian.net/viewtopic.php?f=30&t=47731. I've fixed this on a number of machines, and it doesn't just affect Java, though a lot of software is fine. Anything that uses /dev/dsp (OSS, like old headspace mixer!) or direct ALSA devices could be affected.

If you want help fixing it, please post (in a separate thread!) the output of 'cat /proc/asound/cards' when it works and doesn't. Or you could try running Java through padsp - YMMV.

Either way, please stop posting that this is a reason to not use JavaSound, because it isn't one (which isn't to say that JavaSound doesn't have a range of quirks, as well as a few bugs, that need working around).

Anyway I cannot ask the final users to plug-off their webcams or to modify /etc/modprobe.d/alsa-base.conf, it is not acceptable. Some Linux users are able to install quite "simple" distros like Mageia Linux and Ubuntu and some of them simply do not know how to open a console as an administrator, how could they tinker their OS to make it work even with the indications you provided? A seven-year-old child installed my game; if he had this problem, he would not have been able to solve it even with this information. In my humble opinion, JavaSound should be clever enough to use a capable device as an output instead of taking the first one whatever it is. Therefore, I will go on complaining, I will rather say that Linux users must use this hack or plug-off the webcam to use JavaSound.

Anyway I cannot ask the final users to plug-off their webcams or to modify /etc/modprobe.d/alsa-base.conf, it is not acceptable. Some Linux users are able to install quite "simple" distros like Mageia Linux and Ubuntu and some of them simply do not know how to open a console as an administrator, how could they tinker their OS to make it work even with the indications you provided?

Yes, there are lots of alternative audio API's with Java wrappers (OpenAL, Jack, PortAudio, ASIO, etc.) However, they all require shipping native code, which may or may not be an issue. JavaSound can work reliably cross-platform when used in the right way, and with a solid understanding of how the underlying system works. As a low-level API it's not too bad. As a high-level API it's not great, but there are pure-Java alternatives there.

Sorry for replying so late to a pretty much dead thread, I got fed up with fixing the sound and worked on other more important parts of my game, but now I'm back at the sound problem and if anyone can specifically help me with this it would be appreciated greatly.

Thank you for all the ideas, I've decided to use sampled because I'd rather not import a new library right now.

I'm using java.sound.sampled.* and I have all my code right, nothing is wrong with it, and everything is working.Pardon my oversight on whatever it is I'm missing because, though I'm not new to java at all, I'm relatively new to compiling and whatnot.

Basic problem:Everything runs just fine in Eclipse. Sound plays and everything.When I compile all of it into a jar file using the following process and settings, it runs but plays no sound and then freezes.http://gyazo.com/203ebffccd5c77d07604e022d2a8a6cb

I do not want to use a different program, eclipse works just fine for me and I'm comfortable with it.I'm not going to use any external libraries for this project or change my WORKING code.And all of the files are IN the jar. Where they need to be. I use the same file retrieval method for sprites and loading levels. It works before and after compiling.

I would simply like some help with compiling the jar file so that it works.Any help with the compiling would be greatly appreciated.

Don't use the Runnable Jar option, use the "JAR File" option.How do you load sounds? You're supposed to use Class.getResource(String) or Class.getResourceAsStream(String) and use a forward slash ('/') at the beginning to mean the root of the jar file.

Question 1) Does the game work fine, from your jar, without sound? Are you able to load graphics for example?

Question 2) Do you get an error message?

There are a bunch of ways things can go wrong. Here's a new one I just learned:

Don't use InputStream. Load via the URL, directly to your AudioInputStream. In the following code example, the commented out is the way I used to load sounds, and it doesn't work with Java 7. But the URL form is fine, as InputStream (which throws an exception if the files are not 'markable') is not a factor.

[EDIT: Ack! The class "AudioSystem" is just the name of the class that this code happens to be located in. The file name is a relative address, for example: "audio/beep.wav".]

But, it could very well be a problem with addressing resources. (That is why I asked #1.)Or, you could have an error message that would tell us all. (Run the jar from a cmd prompt, and it will give you error messages.)

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

That's about all I know how to do though. I've had years of coding in school, but the teacher only ever collects our src folder for a project, I'm quite the noob with running jars and programs through cmd, and it's pretty much impossible to find anything useful with a search.

I tried exporting it using "JAR File" but I can't figure out how to make it work and when I tried to use cmd to run it (I tried both the runnable jar and the jar file types with cmd) using java -jar<path> command it told me java was not a recognized as an internal or external command, operable program, or batch file.

Question 1) Does the game work fine, from your jar, without sound? Are you able to load graphics for example?

Question 2) Do you get an error message?

There are a bunch of ways things can go wrong. Here's a new one I just learned:

Don't use InputStream. Load via the URL, directly to your AudioInputStream. In the following code example, the commented out is the way I used to load sounds, and it doesn't work with Java 7. But the URL form is fine, as InputStream (which throws an exception if the files are not 'markable') is not a factor.

[EDIT: Ack! The class "AudioSystem" is just the name of the class that this code happens to be located in. The file name is a relative address, for example: "audio/beep.wav".]

But, it could very well be a problem with addressing resources. (That is why I asked #1.)Or, you could have an error message that would tell us all. (Run the jar from a cmd prompt, and it will give you error messages.)

I changed my code so that it worked that way and now its working in the compiled jar.Also that's interesting about toURI(), that seems to be the case that it doesn't compile.

Well, anyway, it works now and thank you all! Everything else about the game is mostly working, so I may post it in the showcase soon (when it's ready).

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