From: "Alexander E. Patrakov" <patrakov@gmail.com>
To: Lars-Peter Clausen <lars@metafoo.de>,
Arun Raghavan <arun@accosted.net>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Cc: Takashi Iwai <tiwai@suse.de>,
Tanu Kaskinen <tanu.kaskinen@linux.intel.com>,
clemens@ladisch.de,
David Henningsson <david.henningsson@canonical.com>
Subject: Re: PulseAudio and SNDRV_PCM_INFO_BATCH
Date: Sat, 27 Jun 2015 20:28:56 +0500 [thread overview]
Message-ID: <558EC138.8090906@gmail.com> (raw)
In-Reply-To: <557E86DD.8020709@metafoo.de>
15.06.2015 13:03, Lars-Peter Clausen wrote:
> On 06/12/2015 02:29 PM, Arun Raghavan wrote:
>> So I guess the first thing that would be nice to have is a clear
>> meaning of these two flags. With this done, we could potentially get
>> to the API to report the transfer size from the driver.
>
> Yeah, the meaning of those flags is somewhat fuzzy and may have changed
> over time as well. Here is my understanding of the flags, might not
> necessarily be 100% correct.
>
> SNDRV_PCM_INFO_BLOCK_TRANSFER means that the data is copied from the
> user accessible buffer in blocks of one period. Typically these kinds of
> devices have some dedicated audio memory that is not accessible via
> normal memory access and a DMA is setup to copy data from main memory to
> the dedicated memory. This DMA transfers the data from the main memory
> to the dedicated memory in chunks of period size. But otherwise the
> controller might still be capable of reporting a accurate pointer
> position down to the sample/frame level.
>
> So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind handling
> and devices with that flag set might need additional headroom since the
> data up to one period after the pointer position has already been copied
> to the dedicated memory and hence can no longer be overwritten.
>
> SNDRV_PCM_INFO_BATCH on the other hand has become to mean that the
> device is only capable of reporting the audio pointer with a coarse
> granularity. Typically this means a period sized granularity, but there
> are some other cases as well.
I have tried to convert this text into something that can be added to
the doxygen documentation in alsa-lib, but failed to verify the text.
Here is why.
In kernel sources, sound/pci/hda/hda_controller.c mentions
SNDRV_PCM_INFO_BLOCK_TRANSFER. However, sub-period rewinds work fine on
this driver, and the avail granularity is something like 64 bytes. So,
either the description is wrong (i.e., "large blocks, possibly up to one
period size, but 64 bytes still counts as large" is actually meant - but
that would be useless), or the flag is wrongly set in the driver.
--
Alexander E. Patrakov
next prev parent reply other threads:[~2015-06-27 15:28 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 12:29 PulseAudio and SNDRV_PCM_INFO_BATCH Arun Raghavan
2015-06-12 12:32 ` Arun Raghavan
2015-06-12 13:43 ` Alexander E. Patrakov
2015-06-12 13:57 ` Alexander E. Patrakov
2015-06-17 3:04 ` Raymond Yau
2015-06-17 3:38 ` Alexander E. Patrakov
2015-06-15 3:42 ` Raymond Yau
2015-06-15 8:03 ` Lars-Peter Clausen
2015-06-15 11:39 ` Raymond Yau
2015-06-15 12:01 ` Lars-Peter Clausen
2015-06-15 13:34 ` Raymond Yau
2015-06-15 14:16 ` Lars-Peter Clausen
2015-06-16 2:33 ` Raymond Yau
2015-06-17 8:27 ` Lars-Peter Clausen
2015-06-17 9:19 ` Takashi Iwai
2015-06-17 15:09 ` David Henningsson
2015-06-17 16:48 ` Alexander E. Patrakov
2015-06-18 3:15 ` Raymond Yau
2015-06-19 11:19 ` Alexander E. Patrakov
2015-06-19 1:17 ` Raymond Yau
2015-06-19 11:32 ` Takashi Iwai
2015-06-20 3:24 ` Raymond Yau
2015-06-20 6:17 ` Raymond Yau
2015-06-22 2:35 ` Raymond Yau
2015-06-22 6:43 ` Lars-Peter Clausen
2015-06-22 7:49 ` Raymond Yau
2015-06-22 9:41 ` Clemens Ladisch
2015-06-22 11:54 ` Raymond Yau
2015-06-22 12:10 ` Alexander E. Patrakov
2015-06-22 12:34 ` Raymond Yau
2015-06-22 12:49 ` Alexander E. Patrakov
2015-06-22 15:50 ` Raymond Yau
2015-06-22 16:28 ` Alexander E. Patrakov
2015-06-24 5:51 ` Raymond Yau
2015-06-22 22:52 ` Takashi Sakamoto
2015-06-27 15:28 ` Alexander E. Patrakov [this message]
2015-06-27 17:15 ` Clemens Ladisch
2015-06-27 17:58 ` Alexander E. Patrakov
2015-06-28 2:09 ` 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=558EC138.8090906@gmail.com \
--to=patrakov@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=arun@accosted.net \
--cc=clemens@ladisch.de \
--cc=david.henningsson@canonical.com \
--cc=lars@metafoo.de \
--cc=tanu.kaskinen@linux.intel.com \
--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.