Skip to content

Conversation

@rfwatson
Copy link
Contributor

Hi! 👋

While testing this library on Linux (x86_64, Ubuntu 18.04, Alsa k4.15.0-43-generic) I found that the enumerate example panics with the following stacktrace:

<snip>
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_dmix.c:990:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
Listing device: 13. "dmix:CARD=PCH,DEV=0"
ALSA lib pcm_dmix.c:990:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
thread 'main' panicked at 'device not available: "Invalid argument"', libcore/result.rs:1009:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:476
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: rust_begin_unwind
             at libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::result::unwrap_failed
             at libcore/macros.rs:26
   9: <core::result::Result<T, E>>::expect
             at libcore/result.rs:835
  10: cpal::cpal_impl::Device::supported_formats
             at /home/rob/dev/rust/cpal/src/alsa/mod.rs:95
  11: cpal::cpal_impl::Device::default_format
             at /home/rob/dev/rust/cpal/src/alsa/mod.rs:270
  12: cpal::cpal_impl::Device::default_input_format
             at /home/rob/dev/rust/cpal/src/alsa/mod.rs:296
  13: cpal::Device::default_input_format
             at /home/rob/dev/rust/cpal/src/lib.rs:388
  14: portaudio_test::main
             at src/main.rs:18
  15: std::rt::lang_start::{{closure}}
             at libstd/rt.rs:74
  16: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  17: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  18: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  19: std::rt::lang_start
             at libstd/rt.rs:74
  20: main
  21: __libc_start_main
  22: _start

I believe this is caused by this call to the ALSA API returning -22 (EINVAL) for a dmix playback device when it is opened with alsa::SND_PCM_STREAM_CAPTURE.

(It likely also returns the same for a capture device opened with alsa::SND_PCM_STREAM_PLAYBACK but I haven't confirmed yet.)

I believe that the library shouldn't generate a panic in this case. I've attached a PR with a simple fix. My questions are:

  • is it too broad to consider EINVAL as an expected error here? In other words, are there other ways to make Alsa return this value which we wouldn't necessarily expect to be handled like this?
  • should we also add the same logic here and here?

🙏

@rfwatson
Copy link
Contributor Author

rfwatson commented Dec 31, 2018

Just seen #248, closing this in favour of it 🙈

@rfwatson rfwatson closed this Dec 31, 2018
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

Successfully merging this pull request may close these issues.

1 participant