State doesn't reflect current resuming process

[roudikk]

Reproducer:

use std::time::Duration;
use kira::{AudioManager, AudioManagerSettings, DefaultBackend, Easing, StartTime, Tween};
use kira::sound::static_sound::StaticSoundData;

const INSTANT: Tween = Tween {
    start_time: StartTime::Immediate,
    duration: Duration::ZERO,
    easing: Easing::Linear,
};

fn main() {
    let mut manager = AudioManager::<DefaultBackend>::new(AudioManagerSettings::default()).unwrap();
    let sound_data = StaticSoundData::from_file("file.wav").unwrap();

    let mut handle = manager.play(sound_data).unwrap();

    handle.pause(INSTANT);
    handle.seek_to(50.0);
    handle.resume(INSTANT);
    println!("{}, {:?}", handle.position(), handle.state());

    loop {}
}

Output: 0, Playing

I understand that it's async and the position might not have been updated but shouldn't the state be Resuming? I understand that it's about fading in the volume but I also expected Playing to reflect that it had finished loading the track at the current position too.

Edit:
I also though seek_to would update the position even if it's not resumed.

In the above example:

    handle.seek_to(50.0);
    thread::sleep(Duration::from_millis(1000));
    println!("Position: {:?}", handle.position());

Output: Position: 2.2675736961451248e-5

[tesselode]

Everything you do on the main thread is async - positions and playback states will only update the next time the audio thread runs. I could potentially change it so the handle sets that data as soon as you call pause/resume/seek_to/etc. Which behavior do you think would be more useful @roudikk ?

Also, I don't recommend using instant volume tweens - that can lead to noticeable audio clicks when pausing and resuming a sound.

[muja]

I also though seek_to would update the position even if it's not resumed.

I've noticed the same thing. When I seek while the stream is paused, the seek is not immediate, When resuming, it will play a notable length (<1s) from the original position before seeking to the position. Maybe a new issue should be opened for that (if there isn't already)

[tesselode]

@muja that's intentional, the sound has a good number of samples queued up at all times. Currently it's hardcoded to 16384 samples. I wouldn't mind making that customizable.