ALSA: Capture fails from certain devices: `snd_pcm_sw_params` returns EINVAL, triggered by MONOTONIC_RAW timestamps

[ssssam]

Hello, thanks for creating 'cpal'. I have an issue with v0.13.4 on Fedora 34.

Here is what happens when I run the feedback.rs example, from the v0.13.4 tag:

> cargo run --example feedback  -- 'sysdefault:CARD=PCH' 'sysdefault:CARD=PCH'

Using input device: "sysdefault:CARD=PCH"
Using output device: "sysdefault:CARD=PCH"
Attempting to build both streams with f32 samples and `StreamConfig { channels: 2, sample_rate: SampleRate(44100), buffer_size: Default }`.
Error: A backend-specific error has occurred: ALSA function 'snd_pcm_sw_params' failed with error 'EINVAL: Invalid argument'

Caused by:
    A backend-specific error has occurred: ALSA function 'snd_pcm_sw_params' failed with error 'EINVAL: Invalid argument'

If I use the default audio outputs, then the 'feedback' example works as expected. It breaks when I specify a device.

I can recreate the 'feedback' example with this ALSA command, and it successfully connects the two devices I used above:

> arecord -D 'sysdefault:CARD=PCH' --disable-softvol --rate 48000 --format S32_LE --verbose | aplay -D 'sysdefault:CARD=PCH'  --disable-softvol
Recording WAVE 'stdin' : Signed 32 bit Little Endian, Rate 48000 Hz, Mono
Plug PCM: Route conversion PCM (sformat=S32_LE)
  Transformation table:
    0 <- 0
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
<... snip long log...>
Playing WAVE 'stdin' : Signed 32 bit Little Endian, Rate 48000 Hz, Mono

The problem looks related to the struct we pass to the snd_pcm_sw_params() function. I am running Linux 5.11.20-300.fc34; here's that function in Linux v5.11: https://github.com/torvalds/linux/blob/v5.11/sound/core/pcm_native.c

I can see a few ways to trigger EINVAL. I added some debug prints to cpal:

diff --git a/src/host/alsa/mod.rs b/src/host/alsa/mod.rs
index 908d63c..29c78a9 100644
--- a/src/host/alsa/mod.rs
+++ b/src/host/alsa/mod.rs
@@ -1017,6 +1017,7 @@ fn set_sw_params_from_format(
 
     let period_len = {
         let (buffer, period) = pcm_handle.get_params()?;
+        println!("buffer {}, period {}", buffer, period);
         if buffer == 0 {
             return Err(BackendSpecificError {
                 description: "initialization resulted in a null buffer".to_string(),
@@ -1036,6 +1037,10 @@ fn set_sw_params_from_format(
     sw_params.set_tstamp_mode(true)?;
     sw_params.set_tstamp_type(alsa::pcm::TstampType::MonotonicRaw)?;
 
+    println!("{:?}", sw_params);
+    let mut output = alsa::Output::buffer_open().unwrap();
+    sw_params.dump(&mut output).unwrap();
+    println!("{}", output);
     pcm_handle.sw_params(&sw_params)?;
 
     Ok(period_len)

Here's the output:

> cargo run --example feedback  -- 'sysdefault:CARD=PCH' 'sysdefault:CARD=PCH'
    Finished dev [unoptimized + debuginfo] target(s) in 1.55s
     Running `target/debug/examples/feedback 'sysdefault:CARD=PCH' 'sysdefault:CARD=PCH'`
Using input device: "sysdefault:CARD=PCH"
Using output device: "sysdefault:CARD=PCH"
Attempting to build both streams with f32 samples and `StreamConfig { channels: 2, sample_rate: SampleRate(44100), buffer_size: Default }`.
buffer 4704, period 940
SwParams(avail_min: Ok(940) frames, start_threshold: Ok(1) frames, stop_threshold: Ok(4704) frames)
tstamp_mode: ENABLE
tstamp_type: MONOTONIC_RAW
period_step: 1
avail_min: 940
start_threshold: 1
stop_threshold: 4704
silence_threshold: 0
silence_size: 0
boundary: 5296233161787703296

set swparams
Error: A backend-specific error has occurred: ALSA function 'snd_pcm_sw_params' failed with error 'EINVAL: Invalid argument'

Caused by:
    A backend-specific error has occurred: ALSA function 'snd_pcm_sw_params' failed with error 'EINVAL: Invalid argument'

Nothing in that sw_params info seems like it would trigger the EINVAL error that I am seeing.

[ssssam]

This may have the same cause as #601

[ssssam]

After experimenting with different sw_params I found that this works around the issue for me:

diff --git a/src/host/alsa/mod.rs b/src/host/alsa/mod.rs
index 908d63c..7591dd8 100644
--- a/src/host/alsa/mod.rs
+++ b/src/host/alsa/mod.rs
@@ -1034,7 +1034,7 @@ fn set_sw_params_from_format(
     };
 
     sw_params.set_tstamp_mode(true)?;
-    sw_params.set_tstamp_type(alsa::pcm::TstampType::MonotonicRaw)?;
+    sw_params.set_tstamp_type(alsa::pcm::TstampType::Monotonic)?;
 
     pcm_handle.sw_params(&sw_params)?;
 

[ssssam]

This change was introduced in #582. Seems that I can work around it for now by doing: cpal = "=0.13.3"

[ssssam]

Seems that SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW was introduced in Linux 3.17. So I don't immediately understand how it can trigger an EINVAL error in a 5.11 kernel.

[ollpu]

The error probably originates here (called from here). Related

I don't really understand the purpose of that check – does it mean a device (or some layer in between) can only support a predetermined tstamp_type? I guess this is specific to dmix/dshare/dsnoop, where the configuration indeed has to be predetermined to some extent to support multiple simultaneous clients.

[infmagic2047]

I looked into alsa-lib's source code, and here are my findings.

• The tstamp_type param of dmix/dshare/dsnoop is determined at open time, and can't be modified later. To be more specific, snd_pcm_dmix_open() calls snd_pcm_direct_initialize_slave() for the first instance opened, which performs configuration on the underlying device and then copies the configuration back to the parent device. After opening, tstamp_type can't be modified due to the check as noted by @ollpu.
• The default tstamp_type setting for dmix/dshare/dsnoop on my system, and I believe most Linux systems, is "default", which means "keep whatever the underlying device currently uses". Manually setting this to "monotonic_raw" fixes the problem, but we can't expect this on user's system.
• The default tstamp_type setting for hardware devices is "monotonic" when supported, and "gettimeofday" otherwise. Since dmix/dshare/dsnoop can only work with hardware devices, this is the only case to consider.

Conclusion: the default tstamp_type value on most Linux systems is "monotonic", and can't be modified for dmix/dshare/dsnoop. Maybe we should just accept the fact and live with "monotonic" in such situations?

[lu-zero]

Or at least provide a mean to override or fallback, e.g. :

diff --git a/src/host/alsa/mod.rs b/src/host/alsa/mod.rs
index 5bffdfa..baaae34 100644
--- a/src/host/alsa/mod.rs
+++ b/src/host/alsa/mod.rs
@@ -1023,7 +1023,10 @@ fn set_sw_params_from_format(
     sw_params.set_tstamp_mode(true)?;
     sw_params.set_tstamp_type(alsa::pcm::TstampType::MonotonicRaw)?;

-    pcm_handle.sw_params(&sw_params)?;
+    if pcm_handle.sw_params(&sw_params).is_err() {
+        sw_params.set_tstamp_type(alsa::pcm::TstampType::Monotonic)?;
+        pcm_handle.sw_params(&sw_params)?;
+    }

     Ok(period_len)
 }