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