14.09.2014 17:37, Raymond Yau wrote:
=== On the rewind safeguard ===
Result 1: it has been decided that the return value of
snd_pcm_rewindable() is not changed, and the safeguard is returned by a separate function.
It is unlikely to return any value which is safe, it is the responsiability of the application to decide how much can be rewind
You are placing a responsibility on an application without giving it any means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel, but definitely not OK on ymfpci even on infinitely fast CPU (because of the fixed 5 ms interrupt interval). The whole question here is: how is an application supposed to know that?
If pulseaudio assume 20ms process time is require to process two seconds of audio and sleep for 1980ms, it should not assume cpu have infinite power
You are right. The safeguard interval is a sum of the CPU-independent but card-specific part (which is what is being talked about) and a CPU-specific part (which the application indeed should know).
what is the purpose of the timestamp ?
Can the timestamp use to predict when will next period update occur if the timestamp is obtained at previous period update ?
See http://0pointer.de/blog/projects/pulse-glitch-free.html
Why snd_pcm_rewind cannot return error when application just set stop threshold to buffer size and rewind more than the stop threshold ?
I think it does. The problem (due to which we need a safeguard) is that the card-specific minimum number of not-really-rewindable samples exists. E.g., for ymfpci, that would be 5 ms.
:This would require documentation changes for snd_pcm_rewindable(), though, as it officially no longer returns "safe count of frames which can be rewinded". I have difficulty designing a better wording what the function actually means now.
The word "safe" should be removed
That's insufficient. The returned value is valid only in the ring-buffer model for a card that fetches samples absolutely uniformly one at a time, i.e. without any batching, updates the pointer at every played-back sample, and doesn't have any "don't overwrite what I am DMA-ing or I will kill you with IRQs" quirk. I.e., even with the infinitely fast CPU, an attempt to rewind as much as that function returns (and then overwrite) will yield a glitch (that may or may not be detected as xrun even if xrun detection is enabled).