The only problem I've struck so far is that I cannot adjust the volume on any MIDI tunes. The volume controls work for WAV files, but not MIDI.

MIDI volume is a know issue. Unfortunately, this is a bug in Java's built-in synthesizer (not related to any of the library plug-ins). For reference, from 3D Sound with SoundSystem:

Quote

As with most other sound libraries,SoundSystem makes a clear distinction between MIDI and everything else (thus, “NoSound, Silent Mode” refers to everything except MIDI). MIDI music is played in adifferent way than other sources, and it doesn’t require a sound library or codec plug-in towork. Therefore, the core SoundSystem library without any additional plug-ins iscapable of playing MIDI files (with the extension ‘.mid’ or ‘.midi’), but nothing else.MIDI files are extremely small compared to other sound formats, so they can be anexcellent option if memory is a concern (such as in an applet).

Quote

Setting a volume to zero should mean completely silent. However forabout 50% of users the volume of the MIDI source can never become completely silent(it will get quieter, but not silent). Unfortunately, this is a limitation of the synthesizersgenerally available in Java, and can not be avoided until (or if) I write my own MIDIsynthesizer in the future.

The only "easy" solution would be to write a codec plug-in that utilizes the Gervil Software Synthesizer. Unfortunately, that API is licensed by the GPL, which means it wouldn't be an option for commercial applications or applets or for any project you didn't want to be restricted by the GPL. The best solution would be for me to write my own software synthesizer, but that would be a major undertaking, and certainly not a priority in the foreseeable future.

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

Is there any issue with calling SoundSystem.loadSound or SoundSystem.newStreamingSource multiple times with the same file? I'm asking because I'm wondering if it's worth it to have a HashMap in my SoundManager class to prohibit this from happening, or if SoundSystem will just ignore duplicates.

Also, should I just be using addSource every time I want to play a sound? I was thinking I would just make a few sources, but because there is a filename parameter in the addSource method, it seems like you're only supposed to have one sound per source.

Is there any issue with calling SoundSystem.loadSound or SoundSystem.newStreamingSource multiple times with the same file?

For loadSound (and quickPlay) the data from each filename (or identifier if you are loading from a URL instance) is only loaded once. Subsequent calls to loadSound are ignored (SoundSystem has its own HashMap to keep track of what has already been loaded).

For newStreamingSource (and backgroundMusic) nothing is actually loaded until the new streaming source begins playing. While it is playing, SoundSystem reads in chunks of data from the specified file (or URL) and sends them to an available channel to be played. If your single streaming source is set to loop, when the end of stream is reached, it will go back to the beginning and start reading in the data again. (Sorry if that is obvious to you, just making sure you understand what is going on behind the scenes). Thus, calling newStreamingSource multiple times to create multiple streaming sources, and if they are playing simultaneously, SoundSystem WILL BE READING THE DATA MULTIPLE TIMES. If you want to only read the data once or use it multiple times for simultaneously playing streaming sources, you should use the rawDataStream and feedRawAudioData methods instead. This is somewhat more complicated, because you have to come up with some way of managing the data once you read it in (depending on the needs and memory requirements of your particular project). Let me know if you need a simple example to demonstrate one possible way to do this.

Also, should I just be using addSource every time I want to play a sound? I was thinking I would just make a few sources, but because there is a filename parameter in the addSource method, it seems like you're only supposed to have one sound per source.

Each source has only one sound effect associated with it. For normal sources, each audio file is loaded only once and the data is stored in memory. That sample data can be played from as many sources as you like. The source itself is just a few floats and booleans that indicate how and where in 3D space it should play. That information is sent to an available channel when the source is played. Hopefully that makes sense.

You should not have to call addSource every time you want to play a sound. There are a couple of options you can go with. The easiest option is to call quickPlay(), which creates a temporary source, plays it on an available channel, and then removes it from memory (best suited for rapid sound effects in-game, like explosions, gunshots, etc). Another option is to create all the sources you need for each sound effect, and play them when you want them to be played (best suited for menu sounds, ambient looping sounds like crickets, etc).

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

I saw quickPlay, but from the docs I got the feeling that it would also unload the sound file after playing. I don't want to be loading and unloading the same sound a bazillion times, so I figured I shouldn't be using that.

As for the sources - assumedly then I should have one source per entity, or something along those lines? i.e. each unit can play one sound at a time. Is there a way, then, to change the sound associated with a source? Like if I wanted to play a shoot sound and then an explode sound from the same source.

If quickPlay just creates and removes a source from memory, I will probably just go with that instead (assuming the sound files stay in memory), as that should be plenty cheap enough.

I saw quickPlay, but from the docs I got the feeling that it would also unload the sound file after playing. I don't want to be loading and unloading the same sound a bazillion times, so I figured I shouldn't be using that.

Others have said that as well. I need to clarify this point a little better in the guide.

As for the sources - assumedly then I should have one source per entity, or something along those lines? i.e. each unit can play one sound at a time. Is there a way, then, to change the sound associated with a source? Like if I wanted to play a shoot sound and then an explode sound from the same source.

In the case of shooting and explosion sounds, I would either do it with two sources located at the same position, or easier with two calls to quickPlay. Currently, there isn't a simple way to change the sample data associated with a normal source. This is because I made an assumption way back in the beginning of this project that each source would be associated with a single sound effect (this grew out of the underlying libraries OpenAL and JavaSound which also make this assumption in their "Source" and "Clip" entities). Much later on, after I eventually separated and defined the two concepts of "Source" and "Channel", I just continued to make that original assumption, even though it is really no longer a restriction. I could go back and change things a bit to allow this, but I'm not sure if there would be much demand for it. Most people use quickPlay, which was designed for easily playing sound effects in 3D without having to constantly worry about source management.

MIDI volume is a know issue. Unfortunately, this is a bug in Java's built-in synthesizer (not related to any of the library plug-ins).

I had another thought - I could add a method which would allow you to specify the synthesizer to use if you didn't want to go with the default Java synthesizer. That way you could tell SoundSystem to use the Microsoft SW synthesizer if it exists, which would eliminate the volume problem for all Windows users (90% of your clients). Not a perfect solution (half of the remaining Linux, Mac, Solaris, etc users would still experience the volume problem), but it might be a reasonable work-around.

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

I have an issue getting it to work, though, probably because it can't find the sound files. How does it browse for them? How do I search via File or classpath? I see I can put http in there to look for an online resource, but no clear differentiation between local files and things inside the JAR (classpath).

EDIT: Nevermind, I figured it out. But now I have a different problem.

That is the incompatibility that was introduced after LWJGL decided to stop supporting indirect buffers in their binding of OpenAL. This is fixed in the upcoming release. I'm doing some final clean-up work and hope to put it out later this week.

If you want to use a temporary fix in the mean time, make the following changes:

That is the incompatibility that was introduced after LWJGL decided to stop supporting indirect buffers in their binding of OpenAL. This is fixed in the upcoming release. I'm doing some final clean-up work and hope to put it out later this week.

If you want to use a temporary fix in the mean time, make the following changes:

Cool, thanks. If it's done later this week (I'll hold you to that! ) then I'll check back on friday - but I'll need it implemented by Sunday for sure, so if it's not ready on Friday I'll just do the hotfix changes.

The only "easy" solution would be to write a codec plug-in that utilizes the Gervil Software Synthesizer. Unfortunately, that API is licensed by the GPL, which means it wouldn't be an option for commercial applications or applets or for any project you didn't want to be restricted by the GPL.

Just saw this reading through some recent posts having just got back from holiday ..

This statement isn't exactly true. Gervill is GPL with Classpath Exception, as it's part of OpenJDK. That means you can easily distribute it with any project whatever the licence. Might have to keep it in a distinct JAR mind you (never been quite sure about that!)

I am calling this a beta release, because this has been one of the biggest overhauls of the library yet, and I fully expect there to be bugs. I'll post additional updates in the coming days and problems are discovered. I'm working on updating the tutorials as well.

There have been extensive changes since the last release. I'll try and explain all of them quickly.

The big/important changes:

1) I fixed the incompatibility introduced back in LWJGL 2.3 when they stopped supporting indirect buffers.2) I added a Doppler effect algorithm to LibraryJavaSound using sample-rate controls. Note: normal sample-rate ranges in JavaSound are 4KHz - 48Khz, so this can effect how well certain sound effects do with the Doppler effect.3) I implemented a standard interface for Doppler effect, which can now be used with all library plug-ins. There are also new Doppler-effect interface methods in SoundSystemJPCT with SimpleVector parameters in jPCT's coordinate system.4) I implemented a new stream-listener interface, which enables listening for End of Stream events (most useful for playing a sequence of music clips)5) I added in an intelligent auto-search for common MIDI synthesizers when the default is missing. This makes MIDI possible on non-Sun Java versions (such as OpenJDK)6) I added the ability to create normal sources from raw PCM data. Most useful for playing procedurally-generated sound effects.7) I added the ability to check the millisecond position of any playing source8) I added a Mixer ranking system, and an intelligent Mixer-picking based on the functions compatible with each Mixer. This allowed an intelligent work-around for the Java Sound "webcam chosen as default Mixer" bug, as well as the fact that non-Sun Java (such as OpenJDK) may not have the "Java Sound Audio Engine" mixer available.

Additional changes:

1) I fixed a reverse-byte-order bug in CodecIBXM which caused some sounds to be loud and scratchy.2) I fixed a bug where switching libraries caused pre-loaded sounds not to re-load.3) I fixed various bugs when running 64-bit Java plug-in for Firefox on Linux. There are still more (see below).4) I added an error message when attempting to load a missing file from the JAR. Before it acted as if there were no problem if a file was not present.5) I added in a workaround for the Java Sound bug where a random InterruptedException is sometimes thrown when trying to access the default MIDI sequencer.6) I added a varriable to SoundSystemCongfig for specifying which MIDI synthesizer to try first7) I fixed the message-flooding bug that would happen when Mixer controls are not available.8) I fixed various potential thread-synchronization bugs.

There are still several know issues with 64-bit Java on Linux which I am currently working on, including:

1) No MIDI2) Random blocking for a half-second every few seconds3) No sound from Java Sound when switching from OpenAL to Java Sound on the fly4) JFrame 'paint' method causes system graphics to go wacky when playing JavaSound, and can even result in a complete OS lock-up requiring reset.

Please let me know if you run into any problems, and I will work on correcting them right away.

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

Thanks for pointing that out. I tried re-uploading the files, and still getting the old version when I download them I have no idea why the old version is being cached and sent instead of the new version. It must be a bug with either my FTP program or the server, I'll have to try and track it down.

In the mean time, I changed to links to point to the 21 August version archive directory instead of the "latest version" directory, and that seems to be working. Give it a shot and let me know if you are still getting the old version.

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

I'll look into this (could potentially be caused by poor synchronization between the StreamThread and CommandThread). You could also try increasing the streaming buffer size or number (I've had problems in the past with the fact that JOrbis is quite slow, and had to tweak the numbers a bit to avoid skipping when streaming from .ogg files.)

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

I'll look into this (could potentially be caused by poor synchronization between the StreamThread and CommandThread). You could also try increasing the streaming buffer size or number (I've had problems in the past with the fact that JOrbis is quite slow, and had to tweak the numbers a bit to avoid skipping when streaming from .ogg files.)

Ah righto, well its rare, so I haven't taken much notice to it. But I'm using XM files if that helps.

I fixed the new bug I introduced by trying to fix the IBXM reverse-byte-order bug. While this is a relatively minor fix, I ended up having to make small changes to nearly every package, so be sure to download all the new versions (in other words, mix-and-match at your own peril).

Additionally, I finished the JSpeex codec plug-in. Speex-encoded files are generally wrapped into a .ogg container file. (This is what is produced by the binaries you can download from http://www.speex.org/downloads/). While I was digging around, I noticed that there is an "experimental" capability for JSpeex to wrap the data into .wav files as well. Since the .wav format is quite simple to read from (much easier to understand than .ogg), I went ahead and made this codec plug-in useable with either format. By default, it assumes a .ogg container, but I added a method you can call to use speex-encoded .wav files if you prefer instead. Just a reminder - these aren't normal .ogg or .wav files (just the header information is), so obviously they will not work with the other codec plug-ins. I would recommend using a different file extension (like .spx) so you don't get them mixed up with any other non-speex files.

One more note: Speex can also save into "raw" format (i.e., no header information). I didn't make the codec plug-in support this format because it requires the user to define the header information manually, which doesn't mesh well with SoundSystem. However, if using the raw format is a requirement for you, let me know and I can look into it more closely to see if there is a way to support it in my codec plug-in.

As always, let me know if you run into any problems, and I will work on correcting them as soon as possible.

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

I noticed a weird bug in the LibraryJavaSound plug-in today, where if the source and listener have exactly the same position, the source is silent regardless of its intended volume. This is on my PC running Linux and 64-bit Sun Java (a combination which has a multitude of other problems), so I'll verify that this is happening on "normal" computers as well when I get home this evening (if anyone wants to test this for me, try playing a source from position 0,0,0 without moving the listener, and see if you hear anything).

--EDIT--I've verified that this is a 64-bit Sun Java Linux thing (works fine in other OSs and JREs). It is really odd - everything indicates that the source is playing, but no sound. I think maybe I'll play around with the gain controls next (maybe it's assuming incorrectly that a gain of "0" is silent instead of initial gain).

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

OK, it should work now (I just wasn't aggressive enough in the ranker). I am now running exactly the same code as ChannelJavaSound, and if I catch the same exception i give the Mixer a rank of 0. This should remove the webcam as an option, forcing LibraryJavaSound to pick a different Mixer with a higher rank.

OK, it should work now (I just wasn't aggressive enough in the ranker). I am now running exactly the same code as ChannelJavaSound, and if I catch the same exception i give the Mixer a rank of 0. This should remove the webcam as an option, forcing LibraryJavaSound to pick a different Mixer with a higher rank.

25 août 2010 23:29:04 com.ardor3d.renderer.jogl.JoglRenderer updateTexSubImageATTENTION: Attempting to update a texture that is not currently on the card.

SoundSystem shutting down... Author: Paul Lamb, www.paulscode.com

I think it is not your fault, the mixer that is selected only succeeds in playing 2 sounds and does not work anymore after that (it is unable to play the same sounds once more). I advise you not to investigate such a bug as when Java Sound Audio Engine works reliably, the sounds are played correctly. Good night.

I think this is worth looking into, since there are probably a lot of Linux users out there with webcams. I assume the Mixer that works is 'V8237 [plughw:1,1]', correct? I'll look into what those numbers represent - there might be a logical reason why this one works better than 'V8237 [plughw:1,0]'.

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

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