[AudioCue] setSpeed(handle, value) not working

Java Sound & OpenAL
#1

I have this very rough draft of a class to manage an AudioCue instance. The “setSpeed” method is called in another method every game frame and the values are managed in said method, too.

Here’s the code for the class


package ...
import ...

public class Player {

    private URL url;
    private AudioCue cue;
    private int handle;

    public Player(String audioPath) throws MalformedURLException, IOException, UnsupportedAudioFileException {
        this.url = new URL(audioPath);
        cue = AudioCue.makeStereoCue(url, 1);
    }

    public void start() throws UnsupportedAudioFileException, IOException, LineUnavailableException {
        AudioInputStream ais = AudioSystem.getAudioInputStream(url);
        int frameLength = (int) ais.getFrameLength();
        cue.open(frameLength);
        handle = cue.play();
    }

    public void setSpeed(float speed) {
        System.out.println("Previous speed: " + cue.getSpeed(handle));
        System.out.println("Changing speed: " + speed);
        cue.setSpeed(handle, speed);
    }

    public void setVolume(float volume) {
        cue.setVolume(handle, volume);
    }

    public boolean getIsActive() {
        return cue.getIsActive(handle);
    }

    public void stop() {
        cue.stop(handle);
        cue.close();
    }
}

But when I call setSpeed() the speed of the AudioCue instance never changes.

I’m fairly sure I’m doing something wrong but I don’t really know where the error could be. Any help would be great. Thanks in advance.

#2

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.


See 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).

#3

Hi! Thanks for replying to my thread.

To answer your questions:

>Are you hearing the cue at a low, fixed pitch?
Yes, the pitch stays at whatever speed it was initially given and never changes. So a .128 value makes it perpetually slow.

>Maybe it would be possible if the cue being read and set wasn’t the one that is playing and being heard.
Yes, I think that’s actually the problem. Here’s how the cue behaves when opening, playing, and then trying to manipulate things like the speed.

There’s not much to how setSpeed() is called from player, really. I changed it so it only happened when I clicked a button and all it does is call player.setSpeed(value) directly.

It looks like the AudioCue play process ends for some reason, I think? Do I have to run it through a thread and sleep it myself?

> Is it possible that there is something repeatedly calling the same cue that is setting it back to this low value?
Only one button is calling it right now

> 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).
I wanted to check if I was indeed calling it too quickly but now that I’ve changed it so it’s only called on a button press I don’t think that’s the case.

I’m curious, are you running AudioCue from a jar or did you load the code into your project directly?
I added it to my libs as a .jar

I studied the SlidersDemo when I first downloaded the library, thanks!

I’ll keep looking into this myself, and I’ll report back if I find out what’s wrong. Thanks again for answering.

#4

Thanks for keeping me in the loop. I’m curious what you find.

The clip that shows the cue going from Active to Inactive in the break between playing and the speed change is not showing expected results. Once Active, a cue should remain Active as long as it is Playing. If you have set it to looping, that would be indefinitely. Otherwise, the cue would be returned to the pool of inactives at the end of a play.

Here’s another idea to look at: you may have two instances of Player, one that is initially called by your program and another that is attached to your button. Each Player loads its own AudioCue, albeit from the same url, and the two resulting AudioCues would be independent.