Thanks for the replies! It is very heartening to see this willingness to help out.
Sounds like you've got the wrong solution. What exactly is this variable controlling?
The goal is to have a "real-time" gui control of the volume of an ongoing sound being played via a SourceDataLine. My AudioSystem does not expose a MASTER_VOLUME or any other controls for SourceDataLines, though it does so for Clips. From what I am reading, this is probably a good thing. The proliferation of controls slows down the processing of SourceDataLines and according to "Killer Game Programming in Java" most were removed in 1.5.
So, I have a "SoundCue" object which exposes a volatile "desiredVolume" instance variable, and has an internal "currentVolume" variable. Both are floats. At the point where we get a buffer of byte data from the AudioInputStream, I iterate through that buffer and multiply the "currentVolume" float (between 0 and 1) to the audio value. Before doing so, I consult the "desiredVolume" and increment the "currentVolume" towards it. I increment once per "frame". This might seem extravagant in an inner loop at a crucial point, but I think operations like filtering are commonly done at this stage and are considerably more involved.
1
2
3
4
5
6
| if (currentVolume < desiredVolume)
{
currentVolume += 0.0001;
} else {
currentVolume -= 0.0001;
} |
If the increment value is large (while remaining small enough so as to not cause clicks), and the updates from the JSlider stream are in effect "collapsed", then there will a staircase effect to the volume changes as the currentVolume races up to meet the desiredVolume. If the increment is small, the changes are smoother but are rather laggy. I am annoyed at the degree of lag I'm getting now and was hoping for a bit more responsiveness.
Okay this window is starting to jump around and there are more helpful suggestions to answer, so I will reply in multiple posts.
