>> 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 <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. if you look at PA src/modules/alsa/alsa-sink.c , PA try to use pa_smoother_translate() to solve the derviation of audio clock and system clock. this function assume two clocks montonic increase , I wonder that routine can really work if the value returned by pointer call back is a stepping function for usb driver i.e. PA expect the hw_ptr increase at a steady rate but usb can only return the number of urb sent if (u->use_tsched) { pa_usec_t cusec; if (u->since_start <= u->hwbuf_size) { /* USB devices on ALSA seem to hit a buffer * underrun during the first iterations much * quicker then we calculate here, probably due to * the transport latency. To accommodate for that * we artificially decrease the sleep time until * we have filled the buffer at least once * completely.*/ if (pa_log_ratelimit()) pa_log_debug("Cutting sleep time for the initial iterations by half."); sleep_usec /= 2; } /* OK, the playback buffer is now full, let's * calculate when to wake up next */ /* pa_log_debug("Waking up in %0.2fms (sound card clock).", (double) sleep_usec / PA_USEC_PER_MSEC); */ /* Convert from the sound card time domain to the * system time domain */ cusec = pa_smoother_translate(u->smoother, pa_rtclock_now(), sleep_usec); _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
