At Fri, 13 Apr 2007 04:29:48 -0500, Jeff Rush wrote: > > Clemens Ladisch wrote: > > Jeff Rush wrote: > >> Takashi Iwai wrote: > >>> When the playback PCM is in the PREPARED state, it's actually ready > >>> for getting data and trigger. Thus poll() returns POLLOUT. Its logic > >>> is clear. > >> Is this the purpose of the "tick" value that can be manipulated by the ALSA > >> API - in that every "tick" the poll() function will return with POLLOUT to > >> check for more data to be sent? > > > > An output device is ready whenever there is some free space in the > > device's ring buffer. poll() checks the amount of free space when it's > > called and when interrupts occur, i.e., at period boundaries. > > > > If by "tick" you meant "period", the answer is yes. > > I apologize for not using actual function names. When I said "tick", I meant > these: > > int snd_pcm_hw_params_get_tick_time() > "Extract tick time from a configuration space." > > int snd_pcm_hw_params_get_tick_time_max() > "Extract maximum tick time from a configuration space." > > int snd_pcm_hw_params_get_tick_time_min() > "Extract minimum tick time from a configuration space." > > From those descriptions, I've not yet been able to figure out how ticks fit > into the overall system. The only longer description I found was: > > "Minimal sleep > > This parameters means the minimum of ticks to sleep using a > standalone timer (usually the system timer). The tick > resolution can be obtained via the function > snd_pcm_hw_params_get_tick_time(). This function can be used > to fine-tune the transfer acknowledge process. It could be > useful especially when some hardware does not support small > transfer periods." > > I interpreted the phrase "to fine-tune the transfer acknowledge process" to > mean adjusting the time between poll() returns re POLLOUT (and POLLIN) > intervals. Since you've told me that instead that is controlled by the period > setting, i.e. snd_pcm_hw_params_set_period_time(), not the tick setting, I'm > again wondering what ticks are for, especially since they are not settable, > only gettable. This tick isn't so useful in practice, so you can forget it. I think we can deprecate this feature in future. Basically, this can give you more frequent interrupts, especially if the sound hardware cannot have a small period size. Suppose your hardware has minimal period size 32768, which is fairly big. On such a hardware, you'll get irqs less than twice per second with 48kHz. This means that the update of hardware status is done so seldom, because the update function (snd_pcm_period_elapsed()) is called from the irq handler. When the tick is set with small time, e.g. 10ms, then a system timer gives more frequent chance to update _additionally_. OTOH, the condition that poll returns is defined only via avail_min and timeout settings. The frequent irqs may result in more accurate poll timing, but it doesn't change the semantics. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
