Alsa Audio thread '<unnamed>' panicked: Can't set rate

[pacotine]

I'm on Arch Linux. Cargo.toml:

macroquad = { version = "0.4.13", features = ["audio"] }

I get this error: thread '<unnamed>' panicked at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/quad-snd-0.2.8/src/alsa_snd.rs:57:9: Can't set rate.

Thanks in advance for your help.

[pacotine]

I found this related issue: https://github.com/not-fl3/macroquad/issues/584 And https://github.com/not-fl3/quad-snd/issues/49

[pacotine]

Okay, so according to the official ALSA API documentation (https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html), snd_pcm_hw_params_set_rate_near() tries to set the sample rate as close as possible to the requested value (val). Since the function's 4th parameter is NULL, ALSA is free to choose the closest available rate in either direction. However, here's what happens:

• If consts::RATE (i.e. 44100 Hz) is available, it is used ;
• If consts::RATE is unavailable, ALSA selects the closest supported rate (lower or higher, doesn't matter because dir is different from -1 or 1) ;
• If no nearby rate is available, the function returns an error (< 0).

From what I understand, if snd_pcm_hw_params_set_rate_near() fails, it means ALSA could not find any available sampling rate close to 44100 Hz that the hardware can accept. This could be due to hardware constraints or system configuration.

For example, on some systems (like mine, where the sample rate is fixed at 48000 Hz, or as reported in this issue), ALSA only accepts 48000 Hz and cannot round to 44100 Hz or any other value. Since the current implementation panics immediately when snd_pcm_hw_params_set_rate_near() fails, the audio thread is killed, even though the system may still be capable of outputting audio (just at a different rate)...

Would it make sense to handle this case more gracefully? Instead of panicking, perhaps an alternative approach could be explored, such as trying snd_pcm_hw_params_set_rate_minmax(), which allows specifying an acceptable range rather than forcing a single target rate.

What do you think?

[BeauCranston]

For me i'm on arch linux and using pulse audio. I fixed this by installing the pulseaudio-alsa package which allows pulse audio to take full control of alsa. This fixed the problem for me. Hope this helps anyone else.