get_pos much further ahead than actual playback position

I recently updated my music player to rodio 0.22 from 0.21.
No issues on my Fedora 43 desktop.

But on my raspberry pi with updated raspian, audio is not playing and position jumps much faster than 1 sec/sec
I have only tested with .flac files.

I get no errors or warnings when loading files or initiating playback.

Downgrading to 0.21 fixes the issue.

I have attached a video of my player skipping in time, which is the only visual cue i have.
No audio is playing while this is happening.

There are no warning or logs to show.

Screencast.From.2026-02-26.10-08-18.webm

Very strange indeed. The PI is weaker so I'd expect maybe audio artifacting but not skipping. I assume you're progress bar is based on the TrackPosition Source?

The fastest way to figure out what is going on is probably a git bisect. Let me know if you need help with that. Every Rodio build should work. You could try starting at 744f27b after that we did some pref. work maybe that did something.

Shouldn’t the title of the issue be different: audio playback isn’t the problem, but position reporting is?

Is it different between your Fedora desktop (which backend - ALSA direct?) and your Raspberry Pi (PulseAudio?)

@SofusA

Shouldn’t the title of the issue be different: audio playback isn’t the problem, but position reporting is?

Good point!

@SofusA before trying git bisect you can see what happens if you make you're audio chain simpler unless you are using the Player then there is not a lot we can try.

744f27b27816aac74f266dc0cb3c5ffb6226c630: does not work
809ad5d5bd97485ef5ac2736ffddde0c03be881b does work

So it must be related to cpal.

I am using Player on 0.22 and Sink on 0.21

OK that’s a very useful data point.

Does it do this both on your Fedora desktop and your Raspberry Pi? If it’s different please tell me about the differences in configuration.

Yes there are no problems on my fedora 43 desktop.

I am new to audio. What do you mean with configuration?

My desktop is a very default fedora setup, and audio is playing from a usb dac with pipewire.

The raspberry pi is similar with a usb-dac, but installed with the headless “lite” version, so I think it is using alsa directly

Yes, those kind of things are what I mean with your system audio configuration.

Are you using the default buffer size? When you set a fixed buffer size of e.g. 1024 what happens?

Between cpal 0.16 and 0.17 a major change has been that the default buffer size now follows the system buffer size, which sometimes is quite pathological (extremely large). I have an hypothesis that the buffer size is very large and therefore draining the Rodio pipeline.

Same results with a fixed buffer of 1024

I am not 100% sure, because I ran with open_sink_or_fallback

Yes, please try to open explicitly without fallback just to be sure.

If that still does not work, then can you share a branch where you’re making these changes, so I can see if I can reproduce on my RPi?

Removing the fallback fixed it.

So a combination of fixed buffer and no fallback works on 0.22!

Edit: I have been working on this branch: https://github.com/SofusA/qobuz-player/tree/rodio-fix-2

Between cpal 0.16 and 0.17 a major change has been that the default buffer size now follows the system buffer size, which sometimes is quite pathological (extremely large).

how do you feel about limiting that to some maximum in Rodio?

non-intuitive so bug

@yara-blue

@yara-blue

I think might have something of interest. While debugging an issue in cpal I also found a pretty reliable way to reproduce this on my notebook - but it requires a specific file in combination with a SineWaveappend for faster or slower playback (see https://github.com/sandreas/raudio/blob/f9aab19c570ba083733107076d7d1c2a5e9b98e9/src/main.rs#L71).

So it may come down to a decoding / bytestream issue in combination with a wrong handling of "broken data" in cpal. I wrote everything down here:

RustAudio/cpal#730 (comment)

Let me know if I can help you with something else.

@yara-blue

@yara-blue I suspect it’s the mixer getting funny when sources with different sample rates are added, possibly at source boundaries or when the sink is in stopped state.

Is this something you can take along while merging the experiments? Or let me know when you’d like me to take a look.

@sandreas would that M4B file happen to be 22 kHz?

@yara-blue

@yara-blue

I verified it seems to be the sample rate in my case. Here is an example audio file with 22050Hz and the according code example that plays too fast after appending a SineWave. One more thing: I get the impression that the higher the buffer size, the faster it plays - but that might be misleading, I cannot verify this exactly.

One more thing: On a RISC-V device I'm testing it's more like fast-forward (not faster playback) and does not output any sound, so there might be another issue besides this reproducable one.

I'm happy to test any fixes. Thanks

test.zip

Or just create your own:

# create a file that reproduces the error with ffmpeg
ffmpeg -i test.mp3 -f mp4 -ar 22050 -b:a 64k test.m4b

example

use clap::Parser;
use rodio::cpal::traits::HostTrait;
use rodio::cpal::{BufferSize, StreamConfig};
use rodio::{cpal, DeviceSinkBuilder, DeviceTrait, Source};
use std::fs::File;
use std::path::Path;
use std::thread::sleep;
use std::time::Duration;
mod player;

#[derive(Parser, Debug)]
#[command(version, about = "rodio example", long_about = None)]
struct Opt {
    /// The audio device to use
    #[arg(short, long)]
    device: Option<String>,

    #[arg(short, long, default_value = "")]
    file: Option<String>,

    #[arg(short, long)]
    quick: bool,
}

fn main() {
    let opt: Opt = Opt::parse();

    let host = cpal::default_host();

    let device = if let Some(device) = opt.device.clone() {
        let id = &device.parse().expect("failed to parse device id");
        host.device_by_id(id)
    } else {
        host.default_output_device()
    }
    .expect("failed to find output device");

    let mut config: StreamConfig = device.default_output_config().unwrap().into();
    // test must be played first!! otherwise the playback is fine
    // After "test" it plays wav too slow (1/2 speed), and m4b too fast (2x speed)
    // possible side effect: the bigger the buffer, the slower the wav and faster m4b playback

    // config.buffer_size = BufferSize::Fixed(1024);
    // config.buffer_size = BufferSize::Fixed(128*1024);
    config.buffer_size = BufferSize::Fixed(512);

    let stream = DeviceSinkBuilder::from_device(device)
        .expect("failed to create sink builder")
        .with_config(&config)
        .open_stream()
        .expect("failed to open stream");

    let file = if let Some(f) = opt.file.clone()
        && Path::exists(Path::new(&f))
    {
        f
    } else {
        "".to_string()
    };

    let sink = rodio::Player::connect_new(stream.mixer());
    sink.clear();
    let waves = vec![230f32, 270f32, 330f32, 270f32, 230f32];
    for w in waves {
        let source = rodio::source::SineWave::new(w).amplify(0.1);
        sink.append(source);
        sink.play();
        sleep(Duration::from_millis(200));
        sink.stop();
        sink.clear();
    }

    let path = Path::new(file.as_str());
    let file_result = File::open(path);

    // the follwing println! needs to be commented out / in for a "compile change" which pretty reliable results in
    // audio stream error: A backend-specific error has occurred: `alsa::poll()` returned POLLERR
    // workflow:
    // - comment out this line, then cargo run ...
    // - comment in the line, then cargo run ... => stream error should happen after a few seconds
    println!("file result: {:?}", file_result);

    if let Ok(file) = file_result {
        let decoder_result = rodio::Decoder::try_from(file);
        if let Ok(decoder) = decoder_result {
            sink.clear();
            sink.append(decoder);
            sink.play();
            sink.sleep_until_end();
        }
    }
    return;
}

@yara-blue I suspect it’s the mixer getting funny when sources with different sample rates are added, possibly at source boundaries or when the sink is in stopped state.

Well it should not be an issue as the mixer turns every source into a uniform one (new terminology and trait would be FixedSource). So there are no more spans when mixing...

Is this something you can take along while merging the experiments? Or let me know when you’d like me to take a look.

We might want to eventually take out the existing Mixer and force the conversion to FixedSource to be explicit.. I'll keep it in mind!

Think I've found it, normally:

Player::append
calls SourcesQueueInput::append
which adds the source to a shared list
SourcesQueueOutput::next calls SourcesQueueOutput::go_next
takes the source from it and plays it.

Now we are sprinkling through a lot of stop which probably screws up the span stuff. I hate the span stuff and it will be gone in a future Player, completely eliminating this class of bugs. I do not know if it's worth fixing now. Roderick's mega span fixing spree (aka #831) might help a bit, not 100% sure.

@yara-blue

@yara-blue
Thanks for taking the time.

I do not know if it's worth fixing now.

I personally am not in a hurry. When there is an ongoing refactoring process that basically fixes all these problems and improves everthing, I'll appreciate that.

Is there a rough planning when refactoring is ready for testing and do you need support with anything? I'm willing to help...

Is there a rough planning when refactoring is ready for testing and do you need support with anything? I'm willing to help...

If your curious we've hidden the large overhaul over here: https://github.com/RustAudio/rodio-experiments/tree/main. You can use that it should work but it is highly unstable. As in I tend to rename and move things around as we try to get a feel for what is nice. There is also not a lot of documentation yet.

I don't even think the Player struct is hooked up yet. Though there is adapter on FixedSource that will allow you to use it.

We could really use some help reviewing and testing in a week or three, when the above starts getting merged. The exact timing depends on how soon we get #831 and #843 merged, those take priority since they have been waiting quiet a bit.

We could really use some help reviewing and testing in a week or three, when the above starts getting merged. The exact timing depends on how soon we get #831 and #843 merged, those take priority since they have been waiting quiet a bit.

Thank you. Awesome effort. I'm going to work with the new codebase and see what I can do. As I said, I'm not in a hurry but willing to contribute.

Thank you. Awesome effort. I'm going to work with the new codebase and see what I can do. As I said, I'm not in a hurry but willing to contribute.

Great! if you run into anything feel free to ping me on discord (you should be able to find me in the Rodio channel of the Rustaudio Discord). Or open an issue on rodio-experiments. Early feedback is super useful!

@yara-blue

@yara-blue

Today I found the time to try out rodio-experimental. Unfortunately I'm having a hard time running the repository on cpal 0.18.0 (master), which I need because of the alsa overflow bug.

Currently I'm between either an alsa crash (cpal 0.17.3 bug) or no playback issue (rodio 0.22.2) :-) So as long as rodio is not updated to work with cpal master (basically a &config -> config change), I need to fork all three repositories and update the dependencies.

Are you planning to update rodio to work with cpal master soon or would you recommend to work this out on my own? :-)

Rodio master is tracking cpal master now: #866

rodio master works on my machine!

rodio master works on my machine!

I hate to say this but it does not on mine - although it is quite esotheric (RISC-V) it is probably something about the sampling rate, since playing a sine wave before a 32kbps file triggers the problem. I'm working on integrating the new rodio-experimental repository and see if it is fixed then... I'll report back.

@sandreas

@sandreas your issue is distinct from this one. Please try the PR at #868 and continue the discussion about your issue there.

With the positive feedback from @SofusA about get_pos behavior, I'm going to close this one 🥳

@roderickvd

@roderickvd Cool, thank you for your effort. I'll check this out ASAP.

Navigation Menu

Repository navigation

get_pos much further ahead than actual playback position #853

46 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

get_pos much further ahead than actual playback position #853

Description

Activity

yara-blue commented on Feb 26, 2026

roderickvd commented on Feb 26, 2026

yara-blue commented on Feb 26, 2026

SofusA commented on Feb 26, 2026

roderickvd commented on Feb 26, 2026

SofusA commented on Feb 26, 2026

roderickvd commented on Feb 26, 2026

SofusA commented on Feb 26, 2026

SofusA commented on Feb 26, 2026

roderickvd commented on Feb 26, 2026

SofusA commented on Feb 26, 2026

yara-blue commented on Feb 26, 2026

yara-blue commented on Feb 26, 2026

46 remaining items

sandreas commented on Mar 13, 2026

roderickvd commented on Mar 13, 2026

sandreas commented on Mar 14, 2026

yara-blue commented on Mar 14, 2026

sandreas commented on Mar 14, 2026

yara-blue commented on Mar 14, 2026

sandreas commented on Mar 15, 2026

yara-blue commented on Mar 15, 2026

sandreas commented on Mar 20, 2026

roderickvd commented on Mar 20, 2026

SofusA commented on Mar 22, 2026

sandreas commented on Mar 22, 2026

roderickvd commented on Mar 22, 2026

sandreas commented on Mar 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions