I just found a very interesting thread here http://www.java-gaming.org/topics/improving-easyogg/18766/view.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.
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!