Yes, there is a valid reason to use these instead of JavaFX mediaplayer!
By spikes, I'm thinking you mean the same thing as clicks? In other words, it doesn't just start or stop, but there is also a loud click that occurs. This would indicate discontinuities in the sound wave. (If the discontinuities are with the beginning or end of the sound file, probably should use Audacity to edit and put a short fade-in at the beginning or fade-out at the end as needed. Garbage in garbage out also pertains to sound cues.) These clicks can also occur with volume changes (sometimes it is called a "zippering" artifact).
Hickups would indicate dropouts, meaning that the processor is unable to keep up with providing data to the DAC in time. Decompressing does add to the cpu cost for processing a sound and make it more likely that a gap larger than the buffer size would occur.
I may be wrong, but I think the volume controller for the JavaFX media player is kind of lame, and only presents volume changes to the audio stream at each internal buffer transition.
However, with these libraries, you can do the following:
1) decompress the sound and hold it in memory yourself
2) output the data via a SourceDataLine
3) write your own volume changers that spread the volume change out over enough frames that discontinuities are avoided.
This is a fair bit of work, so I recommend using the
AudioCue library to help with the above. It functions like a Clip, but volume can be changed in real time and does so smoothly because it is implemented on a per-frame basis. (It is only a half-dozen files, a couple being just interfaces, and the code is right there available to examine/edit as needed. And it is free.)
In this case, you would decompress the sound with the help of one of these libraries into an array of PCM floats (range -1 to 1). This might take a bit of rewriting, but the hard stuff is already done. Then use the array as a data source for the AudioCue. Since the decompression is done in advance, when playing a sound, the cpu runs significantly faster than the DAC, and you can even set the audio thread priority to HIGH and it will spend most of its time blocking on the SDL write method and not hurt performance of the graphics.
For example, I rewrote a part of a routine that decompresses ogg files and short-cut the process at the stage where it had converted to signed normalized floats, but before it changed those floats to audio bytes and wrote to the java audio output. That is a big part of how the
forest ambience app managed to present as much audio as it did yet stay under 2MB.
