Using JOrbis.jar from JCraft

Java Sound & OpenAL
#1

I just found a very interesting thread here http://www.java-gaming.org/index.php/topic,18766.0.html on EasyOgg. Lots of action in trying to get some additional functionality beyond basic playback working. I am wondering what the various participants are now using??

Not knowing about this, I have been modifying ExamplePlayer instead, from here: http://www.jcraft.com/jorbis/tutorial/Tutorial.html, and made an OggVorbisCueWrapper. I think I recreated some of the coding or functions asked for in the above thread. Stuff I’ve added:

  1. clean stop: an isPlaying boolean is checked once every innermost write buffer. Breaks have been added to pop all the way out to the cleanup code, and the isPlaying boolean is checked on the outer loops as well.
  2. clean volume changes: a desiredVolume float is checked every frame. Some code has been added to ensure that the very start and end of every play() is ramped quickly to or from zero, to eliminate start/stop clicks that arise from starting or stopping an in progress sound abruptly. (I’ve heard that there is a way to do this via a filter working directly on the data, but I haven’t had a chance to follow up on that yet.)
  3. I gone through some rather nutty extremes to make all the JOrbis and JOgg variables stack rather than instance variables, in the hopes of helping out with concurrency problems. Not at all sure if this was misguided or not. :clue:
  4. I’ve made some outer-level objects that handle concurrency via thread pool use.

An example of this code’s use is here, and can be downloaded an run.
www.hexara.com/ffw1.jar

The app is a recreation, in part, of an old composition of mine, pre-MIDI, using asynchronous loops. There is looping, some of it overlapped, some with pauses.

I left the wrapper code in. It isn’t my intention to say this is something that someone can pop in and use. I’m showing it more for feedback and ideas and showing some of what I did.The OggVorbisCueWrapper is in an embaressing state, with ExamplePlayer splayed out and about. I left JOgg and JOrbis in, too. I may have tinkered with them, but I’m pretty sure I always put things back the way they were. Not entirely sure. But that was the intent, that the result would work directly with the JCraft code.

Some problems remain. The main one is that memory use seems to just climb and climb. At first I thought it was a memory leak, but I’m now thinking it is more an attribute of the garbage collection system or my misuse of how the threads are handled. What makes me think it is NOT a memory leak is that if one looks on JVisualVM.exe (snapshots of the memory), and does multiple Garbage Collections on the app after turning off all the loops, the instance counts of all the likely culprits (in either my code or JCraft code) all go back down to zero or one (or a small expected number that matches what is in the code). But I should say, my experience with profiling tools is rather limited.

If one turns off the sounds and “walks away,” it takes a good 10-15 minutes or more for the instance counts to come down. So, I’m wondering how to handle that better. With larger collections of sounds (which I’d like to be able to implement) the memory can climb up to 300MB and start causing playback problems.

But I’m also wondering, if folks have settled on using EasyOgg, or some other OggVorbis wrapper. I’d rather be working with that than knocking my head into known problems. Also, maybe some of the ideas I had for implementing shut down and faders could be added to this code as well, if it hasn’t already been done.

Is there interest still? Should I display the source code? I didn’t change anything in JOrbis or JOgg, but the JCraft code sure looks weird, having things like public instance arrays. I’m guessing the implementor took the C code given by Xiph and rewrote that almost directly. I’m wondering how bad it would be to go through that exersize once again, but optimize it for game playback use, as well as make the code more OOP, as a possible collaborative project.

Thanks for any input!

#2

I use 3D Sound Engine now.

#3

Thanks, Tom.

I note that even Paul doesn’t recommend trying to play back more than one Vorbis file at a time. So I am assuming a lot of the resources issues around OggVorbis haven’t been solved.

I am kind of bummed. There’s a lot of “ambitious” things I want to do, in terms of sound design, using layers and chance methods and the like, but the tech doesn’t seem to be there, at least not something that is sitting out as open source.

WAVs are fast, but take up a lot of space in terms of downloading time.
OggVorbis sound fine and are small, but the JOrbis code ties up a lot of resources.

Current thoughts:

  1. ditch Ogg and just run (during the game), Vorbis decoding. The Ogg wrapper is just a wrapper for streaming, right? Should be able to extract the underlying Vorbis file pre-compilation and decode that at game time. Xiph says the goal was for Ogg to not add more than a couple % points of cpu load, but maybe the potential savings in memory is significant.

  2. look at unpacking sound files at the beginning of the game run, into the faster wav format. I have to learn more about access to temp areas and such, though, especially for Applets.

  3. give up the ambitious ideas altogether or just implement them with wav and have them for people who like sound enough to spend the extra time downloading. Figure if the results are fine, the tech will eventually catch up to work for compressed audio as well.
    :-\

#4

I’m using JOrbis and I seem to be able to decode at least two OGG streams without any troubles. I use 6 buffers of 65kb each for each stream - probably overkill, I think I only really need a third of that - to avoid any glitches. The OggInputStream I use is based on some code from tombr of these parts (it’s in SPGL, and easily located in the Revenge of the Titans source code.

Cas :slight_smile:

#5

Thanks princec! I’ll check it out. I’d LIKE to run more like a dozen at once, if possible, but am probably being too ambitious. But I am also kind of stupid about obstacles and have to ram my head into them a few times. Bloody things up a bit. Slow learner. So much here is new to me.

[EDIT: Ah, I misunderstood. You are converting your OggVorbis files to .wav format and caching them on the client. I started actually looking at the code you generously provided. Nice. I like the management of “single play” cues, too, ending the oldest/lowest priority to make way for new cues. I’m not on the method you are using handling resources via XML yet, but that looks very practical and helpful as well.]

#6

Wow, it sounds like a major hassle to get compressed sound working ok. Thanks for posting about your findings.

I wonder how the big studios do it, like three rings.

#7

@CommanderKeith – I’m making it harder than it needs to be.

#8

Not quite - the actual music is streamed directly from Ogg files. The sound effects are loaded in a single large ogg and decoded directly into memory in one go as ALBuffers where they remain (taking up only a few megs).

Cas :slight_smile: