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.