The consensus is that rewind_safeguard is a workaround for an ALSA bug.
I do not agree with this consensus.
This information should come from snd_pcm_rewindable() from the hw plugin. I.e., on a hw device, it should not be equal to snd_pcm_mmap_hw_avail(). [...] the safeguard should be ideally equal to the granularity of hardware pointer updates.
When snd_pcm_rewindable() is called, it uses the last reported hardware pointer position, which is the boundary between safe-to-rewrite and already-used data. Subtracting the amount of one pointer update step makes it safe for the next pointer update, but it is not known how much time will elapse until the hardware does this update. This time might be too small for the software to have any chance, or even zero, but it is also possible that there is still enough time to do the rewriting up until the reported boundary. And if the software is too slow, it is even possible that two or more pointer updates happen, which would have required a larger safeguard.
In other words: the snd_pcm_mmap_hw_avail() value is possibly ouf of date, but due to the real-time nature of hardware pointer updates, it is not possible to define a safeguard that would be more correct. Writing the buffer near the DMA pointer is always racy.
The only somewhat reliable way to determine if a rewrite is successful is to check _afterwards_ whether the hardware pointer has advanced by too much.
snd_pcm_rewindable is properly not any SAFE value for rewind, it should return zero for those hardware which don't support rewind(e.g, non interleaved or cs46xx)
It is just a theoretical value for rewind since the application don't rewrite immediately
So the application need to estimate the safe guard value from the processing time of the amount of data need to be reprocess /rewrite and CPU speed
Should pulseaudio enable timer scheduling only on those cards which support disable of period interrupt （e.g. hda-Intel and oxygen )?