Re: Master Plan on rewinding

["Alexander E. Patrakov" <patrakov@gmail.com>]

09.09.2014 15:08, David Henningsson wrote:
>
>
> 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)

Currently, as you have already said, we have no such information. This 
information is, however, static for a given card model and should, in 
the future, come from the kernel. Therefore:

1. We need a new flag alongside SNDRV_PCM_INFO_BATCH that kernel drivers 
would set, and alsa-lib to act upon. As indicated in the following 
posts, SNDRV_PCM_INFO_BATCH means a different and not-useful-here thing:

http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/073816.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/073817.html

2. We need a volunteer to crawl through kernel sources and mark drivers 
that cannot report the pointer position with a better-than-one-period 
granularity.

3. Until this is done, we have to either assume that all cards are good, 
or that all cards are bad, or maybe misuse the SNDRV_PCM_INFO_BATCH flag 
as a pessimistic approximation of what we want (and document this 
approximation) if anyone thinks that such misuse will be beneficial in 
the short term.

This leaves the question of "old kernel + new alsa-lib" open.

-- 
Alexander E. Patrakov