jturcotte/chiptrack

Crash when trying to launch

Slushee-a opened this issue · 3 comments

Slushee-a commented

Current behavior

Chiptrack crashes on launch, doesn't open GUI
Reported location:
https://github.com/jturcotte/chiptrack/blob/main/src/sound_renderer/emulated.rs#L748

Expected behavior

Application doesn't crash on launch and GUI opens

Envoriment

  • chiptrack version: 698aa88
  • rustc version: 1.75.0
  • cc version: gcc 13.2.0
  • Machine:
    • OS: Void Linux
    • Kernel version: 6.6.11_1
    • Arch: x86_64

Backtrace:

Found 1 MIDI ports
Connecting to port Midi Through:Midi Through Port-0 14:0
Open the audio player: default
Audio format SupportedStreamConfig { channels: 2, sample_rate: SampleRate(44100), buffer_size: Range { min: 170, max: 1466015503 }, sample_format: F32 }
thread 'main' panicked at src/sound_renderer/emulated.rs:748:10:
called `Result::unwrap()` on an `Err` value: BackendSpecific { err: BackendSpecificError { description: "ALSA function 'snd_pcm_hw_params_set_buffer_size' failed with error 'EINVAL: Invalid argument'" } }
stack backtrace:
   0:     0x56470f39afbc - std::backtrace_rs::backtrace::libunwind::trace::ha637c64ce894333a
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/../../backtrace/src/backtrace/libunwind.rs:104:5
   1:     0x56470f39afbc - std::backtrace_rs::backtrace::trace_unsynchronized::h47f62dea28e0c88d
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x56470f39afbc - std::sys_common::backtrace::_print_fmt::h9eef0abe20ede486
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x56470f39afbc - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hed7f999df88cc644
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x56470f3cb0f0 - core::fmt::rt::Argument::fmt::h1539a9308b8d058d
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/fmt/rt.rs:142:9
   5:     0x56470f3cb0f0 - core::fmt::write::h3a39390d8560d9c9
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/fmt/mod.rs:1120:17
   6:     0x56470f396abf - std::io::Write::write_fmt::h5fc9997dfe05f882
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/io/mod.rs:1762:15
   7:     0x56470f39ada4 - std::sys_common::backtrace::_print::h894006fb5c6f3d45
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x56470f39ada4 - std::sys_common::backtrace::print::h23a2d212c6fff936
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x56470f39c3a7 - std::panicking::default_hook::{{closure}}::h8a1d2ee00185001a
  10:     0x56470f39c10f - std::panicking::default_hook::h6038f2eba384e475
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:292:9
  11:     0x56470f39c828 - std::panicking::rust_panic_with_hook::h2b5517d590cab22e
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:779:13
  12:     0x56470f39c70e - std::panicking::begin_panic_handler::{{closure}}::h233112c06e0ef43e
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:657:13
  13:     0x56470f39b486 - std::sys_common::backtrace::__rust_end_short_backtrace::h6e893f24d7ebbff8
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:170:18
  14:     0x56470f39c472 - rust_begin_unwind
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
  15:     0x56470e55fbe5 - core::panicking::panic_fmt::hbf0e066aabfa482c
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
  16:     0x56470e560123 - core::result::unwrap_failed::hddb4fea594200c52
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/result.rs:1653:5
  17:     0x56470e69d579 - once_cell::unsync::OnceCell<T>::get_or_try_init::h9d00b0c3268884db
  18:     0x56470e6647e7 - chiptrack::main::ha76f7964761ed500
  19:     0x56470e672913 - std::sys_common::backtrace::__rust_begin_short_backtrace::h6a020d3116c63335
  20:     0x56470e6aac49 - std::rt::lang_start::{{closure}}::h5981ac58672a2bec
  21:     0x56470f391307 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hd95060ecd5e1ca24
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/ops/function.rs:284:13
  22:     0x56470f391307 - std::panicking::try::do_call::h6e8cf51db32a6e4b
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552:40
  23:     0x56470f391307 - std::panicking::try::h3a52eefe24fe3c29
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516:19
  24:     0x56470f391307 - std::panic::catch_unwind::h24c28c23c02c3841
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142:14
  25:     0x56470f391307 - std::rt::lang_start_internal::{{closure}}::h705d3c9cbc06ef47
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/rt.rs:148:48
  26:     0x56470f391307 - std::panicking::try::do_call::ha21f52ba13158470
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552:40
  27:     0x56470f391307 - std::panicking::try::h5581346bf6aeb1f8
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516:19
  28:     0x56470f391307 - std::panic::catch_unwind::h7919645a6b72e25b
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142:14
  29:     0x56470f391307 - std::rt::lang_start_internal::h12de51168669836e
                               at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/rt.rs:148:20
  30:     0x56470e6aac3e - std::rt::lang_start::h6ca035e5469b060f
  31:     0x7f8bfa427c4c - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  32:     0x7f8bfa427d05 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:360:3
  33:     0x56470e5607e1 - _start
                               at /builddir/glibc-2.38/csu/../sysdeps/x86_64/start.S:115
  34:                0x0 - <unknown>
jturcotte commented

What sound card are you using? Also is this going through PulseAudio or PipeWire?

I'm setting a buffer_size of 512, which is within the reported buffer_size: Range { min: 170, max: 1466015503 }, so it looks like you might be hitting this issue: RustAudio/cpal#743

From what I can read there it seems like you could try working around the issue by commenting out this line in emulated.rs:

stream_config.buffer_size = cpal::BufferSize::Fixed(buffer_size);`

But be aware that if your default buffer size is larger than 735 this could reduce the smoothness of the UI since I'm running the sequencer from the sound thread and the sound buffer would be refreshed slower than the screen.

Slushee-a commented

Here's what alsactl info spits out for my default output device, in case it's of any use: https://bin.gy/ricepingen

It does seem like commenting this line makes the program launch correctly:

chiptrack/src/sound_renderer/emulated.rs

Line 682 in 6009a0d

stream_config.buffer_size = cpal::BufferSize::Fixed(buffer_size);

It looks, sounds and works perfectly fine.

I can fork the project to try and come up with a more elegant solution (compared to having to comment out a line), if you're interested. Otherwise you can close the issue. Many thanks for all the help!

jturcotte commented

Thanks this looks like a pretty regular setup, I don't really have an idea of what could cause this.

Sadly I'm not sure if there is much to be done from this project's code. The buffer size is set according to the limits reported by cpal's API, so either the limit is wrongly reported (that 512 isn't a supported buffer size would be odd), or something goes wrong before or while forwarding the buffer size to ALSA.

If anything can be done it would be closer to cpal's ALSA backend.