[alsa-devel] semantics of SNDRV_PCM_INFO_BATCH (was: Re: safe support for rewind in ALSA)
kvehmanen at eca.cx
Mon Feb 22 20:15:16 CET 2010
On Sun, 21 Feb 2010, Lennart Poettering wrote:
>> But you can query the SNDRV_PCM_INFO_BATCH flag (it's set by e.g. the USB
>> driver) and adjust your hrtimer-based application's logic based on that
>>> This mean that the wake up time cannot be calculated using as number of
>>> sample/rate since the fuction is not linear especially when using max buffer
>>> size , min period --> max period size is much greater than the watermark
>> Yep, that's what SNDRV_PCM_INFO_BATCH flag warns you about.
> Hmm, could you elaborate a little about SNDRV_PCM_INFO_BATCH? What
> exactly does that mean in general and especially for the timer based
> audio scheduling?
> I am currently not making use of this, but should I?
I'm also looking at this topic from an application developer perspective,
so I can only provide you my interpretation of reading current ALSA code,
but here goes.
I'll also add Eliot (who asked about the same thing, in
) to the cc, and also Takashi, who git-annotate reveals has made most
recent PCM_INFO_BATCH related changes to linux/sound/core/pcm_lib.c. ;)
Anyway, SNDRV_PCM_INFO_BATCH is set by following drivers:
- soc/fsl (mpc52xx/8610)
Common to all these drivers is that audio samples are moved to/from the
ALSA ringbuffer, in bursts, to an intermediary block of memory, and from
there to/from the codec. And most importantly, pointer callback is based
on last ack'ed burst. IOW, hw_ptr jumps in bursts with these drivers and
granularity of hw_ptr is more coarse (affecting snd_pcm_avail(),
snd_pcm_delay() and so forth).
Now the existing documentation for the flag (and user-space
snd_pcm_hw_params_is_batch() API) is rather brief as you've noted, and
AFAIK very few apps use these, so I'm not sure, how much we as app
developers should rely on these semantics (and to the fact that future
drivers will use the BATCH flag in a similar way).
But anyways, the fact remains that snd_pcm_hw_params_is_batch() exists,
and based on a review of current (2.6.33-rc) drivers, majority/all of the
drivers use the flag in the same way.
So for apps like PA, snd_pcm_hw_params_is_batch() is a hint that app
should not rewind closer to hw_ptr than period-size. It also hints that
hw_ptr granularity is more coarse, which might be useful in setting sane
defaults for buffer watermarks and such.
PS Eliot: I didn't respond to your original mail, as I don't really
have even good reading-the-code interpretations for the others.
is set by many, many drivers, but I'm not sure what the
semantics really are (why cs4281 does not set the flag, while
ens1370 sets it for instance). Then again SNDRV_PCM_INFO_BLOCK_DOUBLE
seems very close to BATCH flag, but drivers setting DOUBLE (basicly
just rme9652), _do_ support accurate pointer/hw_ptr reporting, so
there is a difference.
More information about the Alsa-devel