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

Linux ALSA error: problems with unlimited max sample rate #7

Open
ilonachan opened this issue Sep 1, 2024 · 0 comments
Open

Linux ALSA error: problems with unlimited max sample rate #7

ilonachan opened this issue Sep 1, 2024 · 0 comments

Comments

@ilonachan
Copy link

When trying to run the emulator, I get a popup with the following content:
Screenshot_20240901_192424

I've tracked this error down to the function call itself, which gets a sample rate of -1 (or I guess it's also u32.MAX) as input, and I'm pretty certain that shouldn't be happening. Tracing it back even further, the culprit is almost certainly this part of frontend/desktop/src/audio/output/cpal.rs:

        let supported_output_config = output_device
            .supported_output_configs()
            .map_err(|e| {
                error!(
                    "Audio output error",
                    "Error setting up audio output device: {e}"
                );
            })
            .ok()?
            .filter(|config| config.channels() == 2)
            .max_by(SupportedStreamConfigRange::cmp_default_heuristics)?
            .with_max_sample_rate();

Note the with_max_sample_rate call at the end: it just blindly sets the sample rate to the max value. Which is an issue if an engine's reported max sample rate is "infinity", or "maximum u32 value", or (as ALSA probably internally sees it) -1. For reference, I'm on Manjaro Linux, and my audio system is based on PipeWire using Wireplumber (I can figure out version details later if needed), but it's surprising no other sound system had this issue so far (and likely that some will in the future).

My suggested solution would have to be that the program manually checks if the sample rate is -1, and if so uses a fallback value (which can be arbitrarily large short of possibly overflowing i32, so that's good). That could just be a global constant of what we generally know would be physically possible or beneficial.

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