[alsa-devel] HR timer 1000Hz limit since kernel 4.4.0-77

[Takashi Iwai]

On Tue, 23 May 2017 22:49:35 +0200,
Tim wrote:
> 
> 
> 
> 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?

Yes and no.  It can be used, but essentially you're choking your neck
by that.  Whether you can still breathe depends on how the system
performs.

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

Currently it's hard-coded, so you'd need to guess the low limit by
trial-and-error.

> Also, shouldn't the reported HR timer resolution be more
>  in line with this new limit? It reports 1ns resolution.

Well, this resolution defines rather the accuracy (aka granularity).
With HR timer, you can set the resolution in 1us order, e.g. 1021 us.
So, strictly speaking, we should have accuracy and min/max
resolutions, but we were too lazy :)

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

Yes, the timer more than 1khz is really heavy.

> 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?).

I guess it's when snd_timer_info_get_resolution() returns a large
value like 100ms.

> Thank you for great support for a non-member over 10 years.
> Nice talking with you again. Tim.

Good to hear.


thanks,

Takashi