I haven’t updated the JavaDoc yet - there seems to be a bug in NetBeans that is preventing me from producing any JavaDocs, and I haven’t had time to search for a fix.
Corrected a problem in the SoundSystemJPCT extension where source creation methods requiring a String filename parameter stopped working after a previous core library update.
Added additional methods that take URL file references.
Simplified thread synchronization in the core library, making it easy for users to manually manipulate sources by synchronizing on SoundSystemConfig.THREAD_SYNC object.
Fixed a potential deadlock caused by overly-complicated thread synchronization infrastructure in core library.
[/i]
Paul, I’m really impressed with your dedication to your sound engine. Keep up the good work! I may be using it for all sound soon in my own game engine.
This is pretty damn beauteous. I wasn’t aware of this until I saw another post linking this way. I will definitely be using this in my future projects.
I get this error in the SoundSystemPlayerApplet (no sounds/music for me)
Starting up SoundSystem...
Initializing Java Sound
(The Java Sound API. For more information, see http://java.sun.com/products/java-media/sound/)
JavaSound initialized.
Exception in thread "Thread-15" java.lang.InterruptedException: sleep interrupted
at java.lang.Thread.sleep(Native Method)
at com.sun.media.sound.AbstractPlayer.nClose(Native Method)
at com.sun.media.sound.AbstractPlayer.implClose(Unknown Source)
at com.sun.media.sound.MixerSynth.implClose(Unknown Source)
at com.sun.media.sound.AbstractMidiDevice.doClose(Unknown Source)
at com.sun.media.sound.AbstractMidiDevice.close(Unknown Source)
at javax.sound.midi.MidiSystem.getSequencer(Unknown Source)
at javax.sound.midi.MidiSystem.getSequencer(Unknown Source)
at paulscode.sound.MidiChannel.getSequencer(MidiChannel.java:1177)
at paulscode.sound.MidiChannel.init(MidiChannel.java:268)
at paulscode.sound.MidiChannel.<init>(MidiChannel.java:256)
at paulscode.sound.Library.loadMidi(Library.java:1284)
at paulscode.sound.SoundSystem.CommandNewSource(SoundSystem.java:1691)
at paulscode.sound.SoundSystem.CommandQueue(SoundSystem.java:2226)
at paulscode.sound.CommandThread.run(CommandThread.java:121)
Switching to LWJGL OpenAL
(The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org)
OpenAL initialized.
This message indicates that you are not linking with the LWJGL. You can download it from http://www.lwjgl.org. Also, if this is for an application, make sure to use the proper natives for LWJGL.
In SoundSystemJPCT, the zero-parameter constructor does automatic compatibility checking for LWJGL OpenAL first, and then Javasound, so you must link with LWJGL to use this constructor. If you know you will not be using LWJGL, then use the second constructor in which you specify the library plug-in to use (i.e. LibraryJavaSound.class for “software mode”).
–EDIT–
Hansdapf, I am looking into you problem, and I’ll post a fix after I figure out what is causing it.
[quote]SoundSystemJPCT will automatically try to load LWJGL OpenAL “hardware mode”,
and if that fails, it will switch to JavaSound “software mode”.
[/quote]
I thought that meant that if lwjgl was available it will use it otherwise java sound, but what it really means, is that if no hardware accelerated sound is available for OpenAL it will fallback to java sound?
Also, the example applet has crashed (or shut down) my entire collection of browsers twice. Is there a Systems.exit() somewhere in the code? If so, it should probably be skipped for applet versions! Was thinking about using it in applets, so this is quite important to me, whatever the reason was that it was shut down.
I wanted to use this to be able to change the sample rate on sounds. With java Clip I get:
clip.isControlSupported(FloatControl.Type.SAMPLE_RATE) == false
I am not sure what makes it impossible to change sample rate, but I guess it is hardware related. Do you know if I would be able to change the sample rate with this tool using OpenAL in lwjgl on the same rig?
What is the smallest footprint one can get away with for an applet? Currently my applet <300k and I wouldn’t want to multiply the dl size too many times just to play a soundclip at different frequency.
Currently, the compatibility checking for both OpenAL plug-ins check if OpenAL is able to work on the user’s machine - it assumes you as the developer have linked your program with the proper external library. I suppose I could change this, if I can determine an elegant way to detect if the developer has linked with the LWJGL library or not. It just seems obvious to me that if you as the developer know that you are not linking with the LWJGL library, then why would you need to run the compatibility check for the LWJGL OpenAL plug-in anyway? It would always be incompatible in that case.
There is no Systems.exit() called anywhere in the code. Which library plug-in are you using when the problem occurs? I have heard about this happening when using the OpenAL plug-ins, and I have assumed that it is because you are linking with an external native library which requires you to disconnect when you are finished with it. There is a SoundSystem.cleanup() method that you should always call in your program when you are finished with the SoundSystem, to properly shut down OpenAL . However, if your problem is happening when using the JavaSound plug-in, then that would be a new bug. Just let me know if that’s the case, and I’ll look into it.
I don’t know, but I can look into it.
A smaller footprint would be to use the core SoundSystem library linked with the specific plug-ins that you need (for example LibrayJavaSound and CodecJOgg), rather than using the full SoundSystemJPCT extension. The truly smallest footprint would be to copy and paste only the parts of code that you need, which you are allowed to do with the very libral license that I put on the library. It just depends on your needs and how much effort you want to put into it. SoundSystemJPCT is easiest option if you are using it in a jPCT project, but it also has the largest footprint.
This is really strange. It seems from your output, that calling MidiSystem.getSequencer();, an InterruptedException is being thrown. This looks to be a thread synchronization problem related to the Command Thread infrastructure. The only place I can see that I am telling that thread to sleep, though, is from inside its run() method after processeng all the commands. I can’t figure out how it us being put to sleep somewhere between when the command began processing and when the call to MidiSystem.getSequencer() was called.
I suppose a second possibility here is that the InterruptedException happened on a different thread, and Java Sound is just forwarding that message back to the user rather than ignoring it.
Let me write some smaller test programs when I have a little time. I’ll have you run them and hopefully pinpoint where the problem is comming from.
I was browsing the API, first off it looks awesome! I’m planning on using it for my project, however I didn’t notice a way to stream the file contents from an InputStream versus supplying a file name. I’d like to do this because I package all of my resources into a single archive file and access them via streams. Is there a nice way to accomplish this?
All methods that take filenames have equivalent methods that take URLs. I don’t remember if I updated the Javadocs to reflect this change. You should be able to accomplish what you are after using those. Additionally, I added methods for streaming raw audio data directly through a source, which could be used as a last resort if you couldn’t do it with URLs for some reason. Just look at the source code for SoundSystem.java. If I ever have some free time, I’ll update the Javadocs and the tutorial guides.
I’ve discovered that the latest release of LWJGL breaks the SoundSystem library, because they no longer support indirect buffers. I’ve already figured out a solution and I am in the process of implementing it. I’ve been really busy lately so it might be a couple of weeks before I’m ready to post an update.
Sorry for the delay on this, Hansdampf. I am finally getting around to working on this bug (things have been really busy between work, school, and my new son). Before I start digging around, please let me know the following things about your system (to at least give me a direction to start from):
Operating System (XP, Vista, Ubuntu, etc) and architecture (32bit or 64bit)
Browser (IE, Firefox, etc) and architecture (32bit or 64bit)
JVM/Browser plugin (Sun, OpenJDK, etc), version, and architecture (32bit or 64bit)
[quote]Sorry for the delay on this, Hansdampf. I am finally getting around to working on this bug (things have been really busy between work, school, and my new son). Before I start digging around, please let me know the following things about your system (to at least give me a direction to start from):
Operating System (XP, Vista, Ubuntu, etc) and architecture (32bit or 64bit)
Browser (IE, Firefox, etc) and architecture (32bit or 64bit)
JVM/Browser plugin (Sun, OpenJDK, etc), version, and architecture (32bit or 64bit)
[/quote]
oops, I was drunk that day you posted.
[quote=“Hansdampf,post:37,topic:33341”]
I think I’ll focus on this one, since it is the “least common denominator”. First thing I’ll try is to install that particular JVM / plugin on my test machine here to see if I can reproduce the problem. If that doesn’t work, then I’ll try and come up with some test cases for you to run to hopefully narrow down the possible causes.
Hmm. If the problem existed in all versions of Java HotSpot, I would give it a higher priority. But if it only happens in that one version, I’m a little reluctant to put a whole lot of effort into solving it, since that makes it look more like a JVM bug. I will play around with it some to see if there is any obvious fix. Otherwise I’d just say have the user update their JVM if they experience this problem.
Another question - you mentioned that the SoundSystemPlayerApplet didn’t play MIDI or sound. This particular bug we are looking at here is specific to MIDI. Is there another problem with the other sounds?
I know there is an issue with another open-source JVM - the 64-bit OpenJDK Firefox plug-in, where the JavaSound Mixer is not implemented (requiring you to chose another Mixer). Users running this JVM do not hear any sound from the SoundSystemPlayerApplet when running the LibraryJavaSound plug-in. I’m wondering if this is also true for Java HotSpot. I guess I’ll see for myself when I get HotSpot running on my test machine…
