get_pos much further ahead than actual playback position

[SofusA]

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

[yara-blue]

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.

[roderickvd]

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?)

[yara-blue]

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.

[SofusA]

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

[roderickvd]

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.

[SofusA]

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

[roderickvd]

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.

[SofusA]

Same results with a fixed buffer of 1024

[SofusA]

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

[roderickvd]

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?

[SofusA]

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

[yara-blue]

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?

[yara-blue]

non-intuitive so bug