[alsa-devel] Master Plan on rewinding

[Alexander E. Patrakov]

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).

-- 
Alexander E. Patrakov