Re: Master Plan on rewinding

[David Henningsson <david.henningsson@canonical.com>]

On 2014-09-09 10:55, Alexander E. Patrakov wrote:
> 09.09.2014 14:43, Clemens Ladisch wrote:
>> Alexander E. Patrakov wrote:
>>> |---------|---------P----h----p---------|-a-------|---------|
>>>
>>> So, what should alsa-lib return for snd_pcm_avail() and
>>> snd_pcm_rewind()?
>>> The driver only knows that "P" is already used, can infer that "p" isn't
>>> used yet, and knows nothing about samples in the middle.
>> Indeed.  However, the DMA pointer moves asynchronously, so it is possible
>> that it has already moved beyond p when snd_pcm_rewindable() returns.
>> For the samples between P and p, the risk is larger than for those after
>> p, but p is not a boundary where the risk abruptly decreases.
>>
>> It would make sense to report the pointer update granularity, but not
>> to adjust the return value of snd_pcm_avail/rewindable().
>
> OK, I understand your viewpoint, and the phrase "some indicator of the
> actual rewind granularity and/or safeguard ... should be enough for PA
> to be able to pick a suitable default latency" from David indicates that
> he has a similar opinion.
>
> Now the remaining question is: can the proposed heuristic (minimum
> period size for a given sample rate, number of channels and sample
> format) be useful as an upper-bound approximation of the pointer update
> granularity for cards that are "rewindable even further than the nearest
> period"?

Aha, thanks for the explanation. Now I understand that approximation idea.
I don't know if that's a reasonable approximation, but even if it is, 
how would you determine if a card actually has that pointer granularity, 
or if the pointer granularity varies with period size? (I e without 
actually running a stream and measure it)

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic