Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
pacotine opened this issue Feb 16, 2025 · 2 comments
Open

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

pacotine opened this issue Feb 16, 2025 · 2 comments

Comments

@pacotine
Copy link

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
Copy link
Author

pacotine commented Feb 16, 2025

I found this related issue: #584
And not-fl3/quad-snd#49

@pacotine
Copy link
Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant