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.ht... ) 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.