Open bspot opened 1 year ago
Notably, StreamInstant is meant to be monotonic, but the first value breaks that guarantee.
I'm seeing this problem too, but it also looks like it isn't entirely nonsensical:
So it would seem there's some system epoch which is leaking into the first playback callback when using ALSA, after which the epoch is reset to ~now.
I've not analyzed in depth, just peeked at src/host/alsa/mod.rs - and find myself wondering if it might e.g. be a bug in creation_instant
handling?
For me it seems to be the system’s uptime for the first sample (checked with cat /proc/uptime
). After that it is the time since playback started (exactly like in the issue example).
On Linux / ALSA (via PulseAudio), the first time the audio callback is called after the stream is started, the timestamp contains nonsensical values:
Output: