Linux timing error, fixed by rebooting Linux

[paulirotta]

This happened for the first time, Linux Mint with Rodio.

thread 'cpal_alsa_out' panicked at 'get_htstamp timespec { tv_sec: 554, tv_nsec: 806798670 } was earlier than get_trigger_htstamp timespec { tv_sec: 554, tv_nsec: 861573515 }', /home/breath1001/.cargo/registry/src/github.com-1ecc6299db9ec823/cpal-0.13.4/src/host/alsa/mod.rs:860thread ':thread 'cpal_alsa_out17cpal_alsa_out' panicked at ' ' panicked at 'get_htstamp timespec { tv_sec: 554, tv_nsec: 806798670 } was earlier than get_trigger_htstamp timespec { tv_sec: 554, tv_nsec: 862057928 }note: run with RUST_BACKTRACE=1 environment variable to display a backtrace get_htstamp timespec { tv_sec: 554, tv_nsec: 806798670 } was earlier than get_trigger_htstamp timespec { tv_sec: 554, tv_nsec: 861134897 }', ',

--

Since rebooting the computer fixed the issue, it may well be an upstream issue, but something to keep an eye on.

[epleterte]

I hit this (on a Raspberry Pi). Compiled both dev- and master branch of librespot, upgraded rust installation and compiled both again - always with the above panic as result when running the binary. Tried a reboot, and the binary started working.

[reivilibre]

I hit this very frequently. A reboot (but not restarting the process) temporarily solves the problem but it's making my software pretty unreliable since the issue recurs often. Similar to the previous poster, I'm on an ARM64 SBC.

Testing the microphone (with while :; do arecord -d 5 > t; aplay < t; done) still works, so it's not as though there's an inherent problem with recording audio on the system.

[reivilibre]

Since this problem has been making my software very unreliable (it seems like it usually happens within one day of operation), I switched to driving the alsa crate manually and so far this has not caused any similar problem.