[alsa-devel] Playback Devices in PREPARED State Throw Off POLLOUT Events?
jeff at taupro.com
Fri Apr 13 11:29:48 CEST 2007
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
"Extract tick time from a configuration space."
"Extract maximum tick time from a configuration space."
"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:
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
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,
More information about the Alsa-devel