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.
-Jeff