From: "Alexander E. Patrakov" <patrakov@gmail.com>
To: David Henningsson <david.henningsson@canonical.com>,
Clemens Ladisch <clemens@ladisch.de>,
ALSA Development Mailing List <alsa-devel@alsa-project.org>,
Takashi Iwai <tiwai@suse.de>,
Takashi Sakamoto <o-takashi@sakamocchi.jp>
Subject: Re: Master Plan on rewinding
Date: Tue, 09 Sep 2014 15:31:46 +0600 [thread overview]
Message-ID: <540EC902.2030108@gmail.com> (raw)
In-Reply-To: <540EC380.6030903@canonical.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
next prev parent reply other threads:[~2014-09-09 9:30 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-07 15:16 Master Plan on rewinding Alexander E. Patrakov
2014-09-07 18:38 ` Tanu Kaskinen
2014-09-07 19:05 ` Alexander E. Patrakov
2014-09-07 20:51 ` Clemens Ladisch
2014-09-08 3:06 ` Raymond Yau
2014-09-08 7:31 ` Alexander E. Patrakov
2014-09-09 8:43 ` Clemens Ladisch
2014-09-09 8:55 ` Alexander E. Patrakov
2014-09-09 9:08 ` David Henningsson
2014-09-09 9:31 ` Alexander E. Patrakov [this message]
2014-09-21 2:02 ` Raymond Yau
2014-09-22 13:20 ` Lars-Peter Clausen
2014-09-22 13:36 ` Alexander E. Patrakov
2014-09-22 13:44 ` Lars-Peter Clausen
2014-09-23 8:29 ` Raymond Yau
2014-09-23 10:22 ` Alexander E. Patrakov
2014-09-09 13:45 ` Clemens Ladisch
2014-09-09 15:55 ` Alexander E. Patrakov
2014-09-09 16:09 ` Takashi Iwai
2014-09-07 23:12 ` David Henningsson
2014-09-09 19:56 ` Pierre-Louis Bossart
2014-09-10 5:38 ` Alexander E. Patrakov
2014-09-08 7:34 ` Lars-Peter Clausen
2014-09-08 7:59 ` David Henningsson
2014-09-08 8:46 ` Alexander E. Patrakov
2014-09-08 9:26 ` David Henningsson
2014-09-08 10:21 ` Alexander E. Patrakov
2014-09-09 8:43 ` Clemens Ladisch
2014-09-11 3:49 ` Raymond Yau
2014-09-11 4:19 ` A. C. Censi
2014-09-13 9:15 ` Raymond Yau
2014-09-11 5:28 ` Alexander E. Patrakov
2014-09-11 6:21 ` Raymond Yau
2014-09-13 8:57 ` Raymond Yau
2014-09-13 10:43 ` Alexander E. Patrakov
2014-09-13 11:33 ` Raymond Yau
2014-09-13 11:36 ` Alexander E. Patrakov
2014-09-13 18:35 ` Alexander E. Patrakov
2014-09-14 11:37 ` Raymond Yau
2014-09-14 12:07 ` Alexander E. Patrakov
2014-09-15 2:43 ` Raymond Yau
2014-09-15 9:19 ` Takashi Iwai
2014-09-15 9:58 ` Alexander E. Patrakov
2014-09-15 10:08 ` Takashi Iwai
2014-09-15 17:01 ` Pierre-Louis Bossart
2014-09-15 17:14 ` Alexander E. Patrakov
2014-09-15 18:08 ` Takashi Iwai
2014-09-18 1:15 ` Raymond Yau
2014-09-21 9:22 ` Alexander E. Patrakov
2014-09-21 9:53 ` Clemens Ladisch
2014-09-21 10:56 ` Alexander E. Patrakov
2014-09-22 3:27 ` Raymond Yau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=540EC902.2030108@gmail.com \
--to=patrakov@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=clemens@ladisch.de \
--cc=david.henningsson@canonical.com \
--cc=o-takashi@sakamocchi.jp \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.