Crash when recording from motherboard audio, PCM.status().get_htstamp() becomes 0

[nyanpasu64]

Running cpal 7ff54f1. When I run cargo run --example record_wav -- front:CARD=Generic,DEV=0,

   Compiling cpal v0.13.4 (/home/nyanpasu64/code/cpal)
    Finished dev [unoptimized + debuginfo] target(s) in 0.49s
     Running `target/debug/examples/record_wav 'front:CARD=Generic,DEV=0'`
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused

ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused

Input device: front:CARD=Generic,DEV=0
Default input config: SupportedStreamConfig { channels: 2, sample_rate: SampleRate(44100), buffer_size: Range { min: 32, max: 1048576 }, sample_format: I16 }
Begin recording...
thread 'cpal_alsa_in' panicked at 'get_htstamp `timespec { tv_sec: 0, tv_nsec: 0 }` was earlier than get_trigger_htstamp `timespec { tv_sec: 83142, tv_nsec: 928903397 }`', src/host/alsa/mod.rs:855:17
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
   1: std::panicking::begin_panic_fmt
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:460:5
   2: cpal::host::alsa::stream_timestamp
             at ./src/host/alsa/mod.rs:855:17
   3: cpal::host::alsa::process_input
             at ./src/host/alsa/mod.rs:775:20
   4: cpal::host::alsa::input_stream_worker
             at ./src/host/alsa/mod.rs:588:27
   5: cpal::host::alsa::Stream::new_input::{{closure}}
             at ./src/host/alsa/mod.rs:908:17
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[delay, then main thread panics too]

The problem is that upon build_stream_inner(), let ts = handle.status()?.get_htstamp(); is a nonzero value, but when input_stream_worker() calls poll_descriptors_and_prepare_buffer(), stream.channel.status()? returns a status that, when process_input() calls stream_timestamp(), status.get_htstamp() returns zero. Then stream_timestamp() takes ts - trigger_ts which is negative.

Is this an alsa-lib or kernel bug? Or should cpal better handle devices whose timestamps change from valid to invalid?

---

Also cpal doesn't list front:CARD=Generic,DEV=0 among the detected ALSA output devices, even though aplay /dev/urandom -D front:CARD=Generic,DEV=0 --format=S16_LE --channels=2 --rate=48000 works. I think this is a bug as well, but I didn't look into it.

System details

Distro: Arch Linux
Linux kernel: 5.15.13-zen1-1-zen

sudo lspci -v excerpt:

0b:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller
        DeviceName: Realtek ALC1220
        Subsystem: Gigabyte Technology Co., Ltd Device a184
        Flags: bus master, fast devsel, latency 0, IRQ 41, IOMMU group 21
        Memory at fc400000 (32-bit, non-prefetchable) [size=32K]
        Capabilities: [48] Vendor Specific Information: Len=08 <?>
        Capabilities: [50] Power Management version 3
        Capabilities: [64] Express Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [150] Advanced Error Reporting
        Capabilities: [2a0] Access Control Services
        Capabilities: [370] Transaction Processing Hints
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel