Buffer `underrun/overrun` on `96000` and `192000` sample_rate flac

[UnknownSuperficialNight]

Did a cargo update last night and now started to get audio stream error: Buffer underrun/overrun occurred

After a quick investigation, I needed to set the BufferSize manually instead of using the system one (even though this was not an issue before)

Seems for me, I have to do 2048 in order for this to not underrun

builder: DeviceSinkBuilder { device: "Some(Default Audio Device)", config: DeviceSinkConfig { channel_count: 2, sample_rate: 192000, buffer_size: Fixed(2048), sample_format: F32 } }

Example 512 causing errors:

builder: DeviceSinkBuilder { device: "Some(Default Audio Device)", config: DeviceSinkConfig { channel_count: 2, sample_rate: 96000, buffer_size: Fixed(512), sample_format: F32 } }
audio stream error: Buffer underrun/overrun occurred.
audio stream error: Buffer underrun/overrun occurred.
audio stream error: Buffer underrun/overrun occurred.
audio stream error: Buffer underrun/overrun occurred.

That resolved it for me but still weird this became an issue now, so I'm making this issue just in case

I was able to recreate it with the music_flac example

use std::error::Error;
use std::num::NonZero;
use rodio::DeviceSinkBuilder;

fn main() -> Result<(), Box<dyn Error>> {
    let builder = match DeviceSinkBuilder::from_default_device() {
        Ok(builder) => {
            builder.with_sample_rate(NonZero::new(96000).unwrap()).with_channels(NonZero::new(2 as u16).unwrap())
        }
        Err(err) => {
            panic!("error");
        }
    };

    println!("builder: {:?}", builder);

    let mut stream_handle = match builder.open_sink_or_fallback() {
        Ok(stream_handle) => stream_handle,
        Err(err) => {
            panic!("error2");

        }
    };

    let player = rodio::Player::connect_new(stream_handle.mixer());

    let file = std::fs::File::open("song.flac")?;
    player.append(rodio::Decoder::try_from(file)?);

    player.sleep_until_end();

    Ok(())
}

No idea what changed to cause this, i haven't updated my system or modified my system buffer size any time recently

[yara-blue]

Rolling back to the previous Rodio version fixes it?

[yara-blue]

is this the current main vs prev release of prev vs one before? If prev release could you try the current github main just in case?

[yara-blue]

oh nvmd I see DeviceSinkBuilder so that must be current main. Silly me

[yara-blue]

I unfortunately can not reproduce this, though I am cursed with a too powerful system.

@roderickvd I suspect this could be the new queue. There is quite some extra logic in that. Did we benchmark that? Ideally we check the latency between samples, I've been playing around with building a jitter benchmark. Unfortunately its not done yet (needs unsafe fun like reading registers directly to be fast enough so the overhead is low).

Related queue PRs: #817 #822 #818 and finally #825

@UnknownSuperficialNight Thanks so much for trying out the current git main 🥳. Its really nice to find these issues before we release.

Lets hold off any release until we squash this. @UnknownSuperficialNight Could you try the current main with the queue code from the previous release copied in? (any queue code from before PR 822 should do).

[UnknownSuperficialNight]

@UnknownSuperficialNight Thanks so much for trying out the current git main 🥳. Its really nice to find these issues before we release.

No problem :)

Lets hold off any release until we squash this. @UnknownSuperficialNight Could you try the current main with the queue code from the previous release copied in? (any queue code from before PR 822 should do).

Ok i checked out 4ebb379 from #813 using

`git checkout 4ebb3790b23ee08f87fb6afdc44887ecd66ee5de`

This one runs just fine, I'll try to narrow it down more

#814 works but #815 has the issue

I tried ed4dc12

git checkout ed4dc129dec632a2e091db9a9f8b457e24accc46

First commit on that PR, and it has the issue and did a cargo clean just in case same thing

[roderickvd]

I'm 99% certain it's this: https://github.com/RustAudio/cpal/blob/master/UPGRADING.md#4-buffersize-behavior-changes

cpal v0.17 changed BufferSize::Default to rely on the host defaults rather than arbitrary cpal defaults. This exposes shortcomings in system configuration or quirks in drivers, that were previously masked.

[UnknownSuperficialNight]

I'm 99% certain it's this: https://github.com/RustAudio/cpal/blob/master/UPGRADING.md#4-buffersize-behavior-changes

cpal v0.17 changed BufferSize::Default to rely on the host defaults rather than arbitrary cpal defaults. This exposes shortcomings in system configuration or quirks in drivers, that were previously masked.

Can confirm, I went back to 4ebb379 and changed cpal from 16 to 17 and that recreated so that's it

The question is what to do about it?

Just used fixed?

[roderickvd]

Use fixed and in the meantime verify your system configuration. What are you running on?

[UnknownSuperficialNight]

Use fixed

👍🏻

In the meantime verify your system configuration

I presume you're talking about audio config so pipewire and alsa

What are you running on?

Linux x86_64

kernel    │ 6.18.2-gentoo-custom-superficial
distro    │ Gentoo 2.18
cpu       │ AMD Ryzen 5 2600 Six-Core Processor (6)

[roderickvd]

Yes I meant your audio system configuration. So is it bare metal ALSA or do you go through pipewire. If pipewire, what is your quantum set to, etc.

[yara-blue]

Ahh so I was 100% wrong! Thanks for catching this @roderickvd!!

We should at some point wrap some of those errors from alsa with a nice suggestion.

[UnknownSuperficialNight]

Yes I meant your audio system configuration. So is it bare metal ALSA or do you go through pipewire. If pipewire, what is your quantum set to, etc.

I am using PipeWire as the audio server, which interfaces with ALSA. My application registers as alsa_playback under PipeWire

Before

default.clock.rate          = 48000
default.clock.allowed-rates = [ 44100 48000 ]
default.clock.quantum       = 512
default.clock.min-quantum   = 512
default.clock.max-quantum   = 1024

I changed right now to this much better, though even then still issues particularly with 192000 sample_rate songs

default.clock.rate          = 48000
default.clock.allowed-rates = [ 44100 48000 ]
default.clock.quantum       = 1024
default.clock.min-quantum   = 32
default.clock.max-quantum   = 8192

So far I look at some other players like VLC etc and read their quant values from pipewire so far I've done this and i no longer have the issue (basically play it safe)

 let buffer_size = match sample_rate.cmp(&96000) {
    std::cmp::Ordering::Equal => BufferSize::Fixed(2048),
    std::cmp::Ordering::Greater => BufferSize::Fixed(4096),
    std::cmp::Ordering::Less => BufferSize::Fixed(1024),
};

[yara-blue]

192000

We will be downsampling that which takes a while and its putting a lot of samples through the audio pipeline. I've got a fix/improvement planned for the latter. The downsampling issue... that just needs buffering. Could add a source that does that in rodio but for now you have to use the OS

[yara-blue]

@roderickvd might be worthwhile to add the ability to express buffersize in a duration.

[roderickvd]

@roderickvd might be worthwhile to add the ability to express buffersize in a duration.

Yeah, something like that would be very desirable. Still figuring out what the API should be. BufferSize::Duration? BufferSize::Range? Both? Should Range in two variants, one for frames and duration?

Closing this issue for now, as it isn't a Rodio issue.