You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying to run the emulator, I get a popup with the following content:
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.
The text was updated successfully, but these errors were encountered:
When trying to run the emulator, I get a popup with the following content:
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
: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.
The text was updated successfully, but these errors were encountered: