2010/2/23 Kai Vehmanen <kvehmanen@xxxxxx> > 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 >>> >> It is not easy to calculate the correct wake up time if the function is a stepping function since you must keep track of the elasped time instead of relying on the hw ptr positon > [...] > >> 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 > How about cs46xx ? > > 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. > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
