[alsa-devel] semantics of SNDRV_PCM_INFO_BATCH (was: Re: safe support for rewind in ALSA)

[Kai Vehmanen]

Hi,

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 
http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025262.html 
) 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:
   - isa/msnd
   - pcii/bt87x
   - pci/korg1212
   - pcmcia/pdaudiocf
   - soc/au1x
   - soc/fsl (mpc52xx/8610)
   - sparc/dbri
   - usbaudio

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.
    SNDRV_PCM_INFO_BLOCK_TRANSFER/snd_pcm_hw_params_is_block_transfer()
    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.