[SOLVED] sound compiling problem - sound doesn't play in jar

Newbie & Debugging Questions
#1

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 :cranky: )

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 :stuck_out_tongue:

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); )

import sun.audio.;
import java.io.;

@SuppressWarnings(“restriction”)
public class musicPlayer{
AudioStream as;
InputStream in;

	public musicPlayer(){
	}
	
	
	
    public void playMusic(String fna){
    	
		try {
		in = new FileInputStream(new File(this.getClass().getResource(fna).toURI()));
		
		as = new AudioStream(in);
		
		AudioPlayer.player.start(as);
		
		
		} catch (FileNotFoundException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		} catch (URISyntaxException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
    }
    public void stopMusic(){
    	AudioPlayer.player.stop(as);
    }
	
	
}

I also have a screenshot of my project files so you can see where I have them stored in the src folder:

http://gyazo.com/9ad0ee0537666cbac19060c564a0be7c

the classes are in the default package and the tracks I want to play are in the music folder

Any and all help/ recommendations/ redirection/ ideas are appreciated!

#2

This sounds like a classic case of incorrect path. Make sure the file is included inside the jar. Also make sure you add a forward or backward slash at the beginning of the path.

#3

Hi

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.

#4

Yeah, change


          in = new FileInputStream(new File(this.getClass().getResource(fna).toURI()));

to


          in = this.getClass().getResourceAsStream(fna);
#5

:yawn: 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! ;D

#6

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).

#7

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.

@OP
Do NOT use sun.audio as it has been replaced by better API in javax.sound.sampled as nisgma pointed out and the sun.* package and subpackages can change at any time.

#8

No, even though that smiley looks a bit ambiguous - it’s meant to be a yawn!

I assume this is with Clip, which I steer clear of, so I don’t know enough about it or how you’re using it to comment.

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.

No, it’s AN option, as are the various audio libraries built on top of JavaSound that do software mixing, and don’t need you to ship native code - whether or not this is a consideration.

Had written this when you posted, so I’m damn well finishing! ;D Sorry, I have an issue with people playing the “native” card too often!

#9

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.

#10

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).

hmm … I’ve pointed you at a range of pure Java solutions in the past … if that’s what you’d really prefer, take the time to experiment with them!

#11

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.

#12

I didn’t say they could, but this is a distro problem!

Or ALSA could be clever enough not to put a webcam at /dev/dsp.

Or we could all accept that ALSA likes to be fed a single line of data and do software mixing! :wink:

#13

Do you know at least one distro in which this “problem” does not occur?

My webcam has a tiny microphone (not a loud speaker). Therefore, I’m not sure you’re right.

OpenALSoft works fine and allows to avoid tinkering ALSA…

#14

No. There might be ones with a GUI for it though - YaST might have one, but I haven’t used Suse for 6-7 years now so I can’t remember for definite.

/dev/dsp is readable as well as writeable, so it makes as much sense for a microphone as a speaker.

Best workaround and/or test to see if this is the issue may be to wrap the call to Java in padsp, which should reroute /dev/dsp calls through PulseAudio.

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.

#15

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.

Thanks,
Chibi

#16

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.

#17

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”.]


//      AudioInputStream ais = AudioSystem.getAudioInputStream(
//            AudioMixer.class.getResourceAsStream(fileName));

      URL url = AudioMixer.class.getResource(fileName);
      AudioInputStream ais = AudioSystem.getAudioInputStream(url);

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.)

#18

I get no error messages. The jar works fine up until the point where it tries to run the method for sound, then everything hangs.



public Sound() throws LineUnavailableException, UnsupportedAudioFileException, IOException, URISyntaxException {
		
		InputStream in;
		try {
		
		in = new FileInputStream(new File(this.getClass().getResource("/music/Castle.au").toURI()));
		AudioStream as = new AudioStream(in);
		AudioPlayer.player.start(as);         
		
		} catch (FileNotFoundException e) {
			e.printStackTrace();
		}

	}

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 command it told me java was not a recognized as an internal or external command, operable program, or batch file.

#19

Someone correct me if I’m wrong, but I don’t think toURI() works correctly when the resource is in a JAR. Try using philfrei’s method and use AudioSystem.getAudioInputStream(URL)

#20

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).