On the face of it, your code looks fine to me.
It's curious that the speed is .128...
The lowest possible speed value is .125 (three octaves below the recording pitch).
Yet, you are trying to play the cue at 0.85 which is close to the natural pitch.
Are you hearing the cue at a low, fixed pitch?
I am trying to imagine possible causes:
> It seems clear that you are reading from and writing to the same cue instance. Sometimes this sort of behavior indicates a disconnect (e.g., reading from one, writing to another), but I don't see how that would be possible given the directness of your method. Maybe it would be possible if the cue being read and set wasn't the one that is playing and being heard.
> Is it possible that there is something repeatedly calling the same cue that is setting it back to this low value?
> Are you calling it so quickly that it hasn't had the time needed to start transitioning? (Seems unlikely, the transition only takes 1028 audio frames at 44100 fps).
Would it be possible to see the code that makes the call to your Player class, and how it's timing is controlled? (Is it in a game loop, or, occurring via a Timer call of some sort? Or is it occurring directly from some sort of control (e.g., slider) that is sending values? Or is there an intermediary between the control and the game loop?)
I'm curious, are you running AudioCue from a jar or did you load the code into your project directly?
Maybe you already saw this. Here is an example where setSpeed is being used in a program.
https://github.com/philfrei/AudioCue/blob/master/src/main/java/com/adonax/audiocue/supportpack/SlidersTest.javaSee the class SoundHandler, method "update". Only thing non-obvious (I think) is the calculation where the input (ranging from 0 to 1) is scaled to accommodate an output ranging +/- two octaves (0.25 to 4).