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).
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).
Looking good…
Would this be a drop in upgrade or are they API/functionality changes as well? I like the new features (especially the midi synth search and ability to find the current head location in a sound!), but don't have the time this week to do much more than a jar drop-in and stability test.
Thoughts?
In most typical usages, it should be plug-and-play upgrade from previous version (switch out all packages, though- mix and match between versions probably won't work). Special cases where there might be slight changes required are if you are doing analysis of SoundSystemException's, because I changed that class quite significantly. The other case that would require changes might be if you extended the SoundSystem class to do some non-typicle things like direct use of CommandObject instances.
Cool! I'll give it a go this week. We haven't started doing anything too fancy with the audio yet, but one of the things we're starting to look at is using MaxMSP to create dynamic scenery sounds which can be fed into the application. I'd like to make sure that we're using the latest and greatest before we go super deep.
NOTE: The new forum will not let me edit my previous posts, so ignore my first post since it has outdated links
NVM, editing seems to be working now
Bug-Fixes Update
Sound System
JavaSound library pluggin
WAV codec pluggin
What’s New:
- Updated CodecWav link to current version
- Improved LibraryJavaSound performance slightly in non-Sun Java versions
- Handled rare pan-control exception
- Fixed fadeOutIn bug which caused fade-in effect to be silent
PaulLamb said:
NOTE: The new forum will not let me edit my previous posts, so ignore my first post since it has outdated links
How does this problem express itself? I suppose you have noticed the link to "Edit Topic" post is further up, above the "Quote" Link?
normen said:
How does this problem express itself? I suppose you have noticed the link to "Edit Topic" post is further up, above the "Quote" Link?
It is working now, perhaps just a temporary problem with my browser or a delayed connection from heavy traffic? The behavior was, after clicking the "Edit Topic" link, it would clear out some space on the page, but the edit textbox never appeared. For reference, I'm running Ubuntu Lucid 64-bit and Firefox 3.6.11 64-bit.
Hey Paul. I’m having a bit of trouble with the queueing code. I want to implement background music which has a beginning intro track that plays first. After that track finishes, the repeating portion of the background music should play. I’m not quite sure how to implement this. Can you help me out?
Hi, ddrfreak,
The easiest way to to have a music lead-in track followed by a repeating track is with the queueSound method. Create your streaming or MIDI source as looping, using the lead-in track, and queue up the repeating track:
Code:
mySoundSystem.backgroundMusic( "whatever it's called", leadInTrack, true ); // or use newStreamingSource method
mySoundSystem.queueSound( "whatever it's called", repeatTrack );
Yeah, I made an attempt at doing that but it didn’t work correctly.
So I have method for loading and queue background music:
sound is an instance of SoundSystem.
[java]
public static void queueBGM(String filename) {
String bgmName = filename.substring(0, filename.indexOf("."));
String ext = filename.substring(filename.indexOf("."));
currentBGMIntro = bgmName + “-intro”;
currentBGM = bgmName;
currentFilename = filename;
sound.newStreamingSource(true, currentBGMIntro, currentBGMIntro + ext, false, 0, 0, 0, SoundSystemConfig.ATTENUATION_NONE, 0);
sound.queueSound(currentBGM, currentFilename);
}
[/java]
Then I have a method for actually starting the background music:
[java]
public static void startBGM() {
sound.play(currentBGMIntro);
}
[/java]
The result is that when I call the startBGM method after calling queueBGM, it plays the intro track and then the music stops.
I assume that I am merely coding it incorrectly. So how should I fix it?
I also just noticed that the queueSound method does not allow you to specify that the sound should repeat. How do I control that?
Posting to circumvent page bug.
Just realized that I was queuing incorrectly, I wasn’t setting the queue course name to the previous file. However, now that I hear the next track play, I noticed that there is a slight lag upon the track change. Is there anyway to eliminate this lag?
I have not noticed this myself before, but I suppose it is possible that my computer here is fast enough that I don’t notice a delay in reading the first buffer of data. I do know that JOrbis is relatively slow at decoding data, so that could be coming into play here. Let me take a look at the code to make sure a buffer of data (or more, depending on streaming buffer count setting) is being read in ahead of time before the first sound finishes playing. This is the way it should behave, but I haven’t looked at this part in a while.
Another thing to verify is that there isn’t any silence at the end of your lead-in track (i.e. it should end right after the last note plays so there is no delay before the next track can start to play).
There is a second way to solve this if I can’t figure out any other way to fix the problem, but it would be a bit more complicated. It would be to use a raw data stream, and feed in the information manually rather than queuing up a sequence. I’d rather figure out what is causing the delay, though, rather than forcing folks to use a lower-level method to do such a common function as queueing up music tracks.
PaulLamb said:Let me take a look at the code to make sure a buffer of data (or more, depending on streaming buffer count setting) is being read in ahead of time before the first sound finishes playing.
Wow, no it is not.. how the heck did I miss that until now?? I'll fix this right away..
At first I was using JOrbis. So I switched to JOgg to see if it produced lag. And it does, even more noticeably. The tracks don’t end as smoothly. Also, I am using the Java Sound Library. Would using another library decrease the lag?
Also, I did listen to my tracks again to make sure the lag was not there, and it is not. The tracks work perfectly. We have a working sound system for our game, but the background music and sound effects system is separate. Plus, we don’t have any control over volume of the stopping of tracks after they are started for some reason. This is why I am attempting to rework our sound system with your better code. Our current sound system is capable of going from the intro to the main track without a noticeable lag, and I believe it uses the JOrbis codec.
Right, it is a bug in my code, not yours. I’ll post an update shortly.
Cool, thanks.
Man, now I remember why I wrote it this way - because samples in the queue may not necessarily be in the same AudioFormat as each other. The current method works fine on my computer, but apparently is not good enough in every instance. This will be a bit more difficult to fix than I initially thought. It’ll probably take me a couple of days to figure out a suitable way to read in buffers from the subsequent samples ahead of time and then transition to a different audio format when the end of each sample is reached.