[alsa-devel] Playback Devices in PREPARED State Throw Off POLLOUT Events?
tiwai at suse.de
Fri Apr 13 12:14:41 CEST 2007
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
> 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
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.
More information about the Alsa-devel