[alsa-devel] Playback Devices in PREPARED State Throw Off POLLOUT Events?

[Takashi Iwai]

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