Yeah. I’m working with a group of five and my laptop seems to be the worse for JME. The graphics don’t load correctly and everything is slower. So it’s no surprise that the audio lag happens on my computer and not yours. However, we’re trying to make the game playable on many different setups, which is the goal of just about any game, so what ever you can do to help with the lag would be much appreciated. Thanks a lot. Your SoundSystem code is so much more reliable than what we currently have implemented.
Hey, I’m experiencing a problem where my ogg file is getting cutoff at the end. It is a sound effect that is less than a second long and it is played by the following code:
[java]
public static void playSoundEffect(String filename, float x, float y, float z) {
sound.quickPlay(true, sfxDir + filename, false, x, y, z, SoundSystemConfig.ATTENUATION_ROLLOFF, SoundSystemConfig.getDefaultRolloff());
}
[/java]
sfxDir is a string that is added to the beginning of the filename so that it is pointed to the right place.
In this case, the method is called when an attack is used and is based the local translation x, y, and z values of the attack user’s model. Is there a way to fix the cutoff?
Yes, I am working on fixing a bug in CodecJOrbis, which happens with certain .ogg files (seems to be a problem with the way versions of Audacity export .oggs). The last block/chunk of data seems to be getting dropped somehow. You will notice that a number of players (including VLC, and even some of the tutorials on the official JOrbis website) have the same behavior with these .ogg files, while other players can play them just fine. It is probably a problem with the way I am interfacing with JOrbis, and I’ve downloaded a working player which I am comparing to my code to see if I can spot what needs to be changed. For more information, I have a thread going on my website about the issue:
Creating OGG Vorbis audio problems
PaulLamb said:
Yes, I am working on fixing a bug in CodecJOrbis, which happens with certain .ogg files (seems to be a problem with the way versions of Audacity export .oggs). The last block/chunk of data seems to be getting dropped somehow. You will notice that a number of players (including VLC, and even some of the tutorials on the official JOrbis website) have the same behavior with these .ogg files, while other players can play them just fine. It is probably a problem with the way I am interfacing with JOrbis, and I've downloaded a working player which I am comparing to my code to see if I can spot what needs to be changed. For more information, I have a thread going on my website about the issue:
Creating OGG Vorbis audio problems
I wrote an OggInputStream many years ago. It was based on the examples that came with JOrbis. I can remember fixing a bug where the end of some files were cut off at the end. Some very short sounds didn't even play at all. The source code is located here if you want to try it or have a look:
http://home.halden.net/tombr/ogg/ogg.html
Hey, I just thought I would give a progress update. Using a working JOrbis player applet, I’ve been working backwards to turn it into a ICodec implementation. I’ve gotten it into the proper form, and just have to make it utilize the proper buffer sizes as set in SoundSystemConfig, and put in proper logger messaging and thorough comments. I should have the new and improved CodecJOrbis ready in the next couple of days.
Sweet, thanks a lot. I’ll be looking forward to the update.
I reached the point where the behavior popped back up again while adjusting the buffer sizes. I’ve been keeping backups as I go along, so I am able to go back to a specific point before the problem appears. Strangely though, I can’t seem to figure out exactly what in the code is causing the problem. Twice I’ve made a couple seemingly minor changes, ran a test and noticed the problem, and then tried to comment out what I changed - but the problem persists until I delete the code and paste back in the working version ???
This is very perplexing - I’m sure it is something very simple that I just keep missing. I’m going for round three - hopefully this time will be the charm…
Wow, this is hilarious. So I finally got the thing set up so it will return a buffer of the specified size. With the following line of code, it works:
[java] private static final int BUFSIZE=4096*2;[/java]
But when I change it to the following, the end gets cut off:
[java] private static final int BUFSIZE=SoundSystemConfig.getStreamingBufferSize() / 2;[/java]
This certainly confirms that the problem is directly linked to the size of the return buffer, but I still haven’t a clue yet why. I’ll play around with some various different values to see if I can determine what buffer sizes cause the problem, and maybe that will tell me something. I am definitely scratching my head at this point.
For reference (in case someone can spot something obvious), the way I set up the method is like this:
–EDIT-- Removed, due to bug in the forum which deleted a section of the code. Forum administrators, if you are unaware of this bug, I can provide the section of code that caused the behavior. If anyone wants to see the method I originally tried to put here, I have it posted on my forum under this thread.
Obviously, even if I do get this working, the whole “breakOut” concept to keep the nested loops is rather hackish (it should function just fine, but it looks atrocious). Unfortunately, all my prior attempts to do set this method up without using all those pesky loops has always resulted in the end of the file getting cut off. I’m hoping that if I can figure out what is causing the problem here in this setup which uses only slightly modified code from the working player, I can use that knowledge to come up with a cleaner method.
Success! I got it working!
Turns out that JOrbis prefers decoding 8192 bytes of data at a time (16384 bytes after conversion). Larger values work most of the time, but that cut-off behavior will occur for some .ogg files. I personally think this is a bug with JOrbis itself, but easy enough to work around.
I’ve uploaded a temporary codec (the hacky nested-loop version), which I’ve called CodecJOrbisTMP. I plan to fix my original CodecJOrbis now that I know what the cause of the cutoff behavior is, but I would first like to verify that the problem is really fixed now. Could you try out the temporary codec and let me know if none of your .ogg files are being cut off any more? I have no idea how compatible this codec is, since it was created entirely from scratch and untested, so don’t worry if something that worked before is now broken (I’m not going to use this codec anyway - I’m just interested in seeing if the cutoff problem is finally solved for good by limiting the decode-buffer size to 8192).
CodecJOrbisTMP (temporary debug version)
CodecJorbis, Bug-Fix
Jorbis codec pluggin
- Fixed a bug where certain types of .ogg files created in versions of Audacity were cut off just before the end of the sample.
Thanks a lot! It works great! No cutoff!
Excellent, now back to that stream-queue transition delay problem…
Ok, give this a try (whichever plugins you are working with):
Sound System core
JavaSound library plugin
LWJGLOpenAL library plugin
JOAL library plugin
What it does is read the initial buffer(s) of data from the next sound in the sequence before the previous sound finishes playing. Let me know if it solves your music transition delay problem (I can’t reproduce the behavior here, but I think it should work).
If you are still getting the delay, I wrote in an optimization hack that you can utilize - just make sure that all your music files in the queue are exactly the same AudioFormat once decoded (including channels, sample rate, sample size, etc). This is the fastest that I can possibly make the transition, so fingers crossed that it will eliminate the delay if the other optimizations aren’t enough. You can set this optimization with the following command:
[java]SoundSystemConfig.setStreamQueueFormatsMatch( true );[/java]
Wow, thanks a bunch. The switching is just about seamless. We also need to make sure that we are being precise with our sound files. I will test your optimization hack tomorrow and get back to you on it. Thanks again!
Any problems with the transitions, ddrfreak? One of my testers has reported a problem with sounds only playing once and not being stoppable. When I get the problem figured out, I’d like to post an official release, but I want to verify that the transition code doesn’t need any more work, first.
The transitions are not completely smooth but I think they will be good enough for our purposes. There is also a little popping noise when we stop tracks by calling the stop method. Other than that, no problems for me.
Is the popping when using the JavaSound library plugin, and is it something new that appeared after I added the transition code? Is there any popping at the time the transition occurs?
I am using the JavaSound library and I’m not sure if the popping sound occurred before the newer code. A small pop happens when the transitions occur.