[ALSA] supported_formats panics on certain device

[vim-zz]

I use x86 Linux machine which has some sound card installed. When running the enumerate example it lists some devices successfully, some fail with errors (which is ok and expected), but then it panics on a certain device with the following output:

11. "dmix:CARD=AT2020USB,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:945: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:511
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:426
   6: rust_begin_unwind
             at libstd/panicking.rs:337
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:92
   8: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::expect
             at /checkout/src/libcore/result.rs:809
  10: cpal::cpal_impl::Device::supported_formats
             at src/alsa/mod.rs:95
  11: cpal::cpal_impl::Device::default_format
             at src/alsa/mod.rs:270
  12: cpal::cpal_impl::Device::default_input_format
             at src/alsa/mod.rs:296
  13: cpal::Device::default_input_format
             at ./src/lib.rs:388
  14: enumerate::main
             at examples/enumerate.rs:15
  15: std::rt::lang_start::{{closure}}
             at /checkout/src/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:105
  18: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:374
             at libstd/rt.rs:58
  19: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  20: main
  21: __libc_start_main
  22: _start

[armyofevilrobots]

Same here:

        for device in cpal::devices(){
            let formats = device.supported_input_formats(); // LINE 100
            match formats{
                Ok(formats) => {
                     for format in formats{
                         info!("Device {} has IN_FORMAT: ch:{}, fmt:{:?}",
                               &device.name(), format.channels, format.data_type);
                     }
                }
                Err(_) => {
                    error!("Unable to find supported formats in device {}. Disconnect?", &device.name());
                }
            }
        }

Results in:

ALSA lib pcm_dmix.c:1035:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_dmix.c:1035:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
thread 'main' panicked at 'device not available: "Invalid argument"', src/libcore/result.rs:1009:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:211
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:491
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:398
   6: rust_begin_unwind
             at src/libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:95
   8: core::result::unwrap_failed
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::expect
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/result.rs:835
  10: cpal::cpal_impl::Device::supported_formats
             at /home/derek/.cargo/registry/src/github.com-1ecc6299db9ec823/cpal-0.8.2/src/alsa/mod.rs:95
  11: cpal::cpal_impl::Device::supported_input_formats
             at /home/derek/.cargo/registry/src/github.com-1ecc6299db9ec823/cpal-0.8.2/src/alsa/mod.rs:252
  12: cpal::Device::supported_input_formats
             at /home/derek/.cargo/registry/src/github.com-1ecc6299db9ec823/cpal-0.8.2/src/lib.rs:374
  13: onair_sonoff::main
             at src/main.rs:100
  14: std::rt::lang_start::{{closure}}
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libstd/rt.rs:74
  15: std::panicking::try::do_call
             at src/libstd/rt.rs:59
             at src/libstd/panicking.rs:310
  16: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:102
  17: std::rt::lang_start_internal
             at src/libstd/panicking.rs:289
             at src/libstd/panic.rs:398
             at src/libstd/rt.rs:58
  18: std::rt::lang_start
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libstd/rt.rs:74
  19: main
  20: __libc_start_main
  21: _start

[armyofevilrobots]

Looking at:
https://github.com/michaelwu/alsa-lib/blob/master/src/pcm/pcm.c#L2063
I can see a ton of places that return -EINVAL, and I don't expect any downside to just returning the same kind of format enumeration error... Unless there is some kinda cleanup we need to do there.

Regardless, I'm going to attach a very simple PR to this issue, since the change is completely fixed in my env with this one-liner, and I haven't seen any stability impact yet.

[mitchmindtree]

This has since been addressed, though I don't remember which commit exactly adds the case for handling the -22 error code. #286 also removes almost all internal panic!s within the synchronous API so it should at least be possible to handle these cases in user code now. Feel free to comment or re-open if this error pops up again!