On 05/23/2017 02:01 AM, Takashi Iwai wrote:
On Mon, 22 May 2017 18:30:27 +0200, Tim wrote:
Hello, ever since kernel 4.4.0-77, there seems to be a limit on the ALSA HR timer, I can't set it above 1000Hz (snd_timer_params() fails with -22 invalid argument). I used to be able to set the rate much higher than that. Been observed in two completely different distros, one with a much newer kernel. How can I overcome this limit?
It's a recently introduced limit to avoid the too condensed spinlocks that may lead to a kernel lockup (the commit 71321eb3f2d0). If sub-ms timer is really required, we may introduce some module option to allow it, but it's the last-resort.
What's the exact use case?
thanks,
Takashi
It's the MusE Sequencer Project. We use the timer to drive our ALSA playback.
A limited 'high resolution' timer with no way to change it. Sounds a bit... drastic. But I can understand why a limit had to be done. I often wondered if the HR timer could really be used reliably at high frequencies. A dream?
We can live with 1000Hz. But I need to know: Where can we find and read this limiting value? Because we need to set the 'autostart' member in the timer params structure, and the structure wants a valid 'tick' value, so we first need to know about that limiting value. Also, shouldn't the reported HR timer resolution be more in line with this new limit? It reports 1ns resolution. This confused our app, thinking it was OK to go ahead and use this timer at a high rate, yet it failed. We need the limiting value so that we may skip this timer if a better one is found (rtc hpet etc.) And I need to ask, under what conditions might snd_timer_params_set_ticks() subsequently cause snd_timer_params_get_ticks() to report < 1 ? The example test timer.c uses this, and we do to, but we're not sure why it's needed - since it did not fail when we asked the HR timer for > 1000Hz (shouldn't it fail with < 1?).
Thank you for great support for a non-member over 10 years. Nice talking with you again. Tim.