System Timer Resolution - and Audio apps

[Gtrax]

Hello folk at LF.

I need some expert help about how best to manage the kernel timer resolution, which, set as it is, is crippling for any real-time audio applications (in this case MIDI sequencer 'Rosegarden'). The problem has been reported before, but the searches do not reveal clearly explained routes to a solution. Almost anything that involves 'kernel pre-emption' and 'latency' is very touchy territory, involving trade-offs in desktop response, and this is not something I know much about.

I will set out what I have, and what I have discovered so far.

The system Is a Debian 'Etch', with kernel 2.6.18-4-686 and KDE desktop.
The mothermoard is ASUS A7N8X motherboard with AMD Athlon XP2500+ Barton processor, not (yet!) overclocked.
There is 1.5GB of DDR400 memory. Not the latest and greatest - but surely adequate.
The 'Rosegarden' application reports..

System timer resolution is too low
Rosegarden was unable to find a high-resolution timing source for MIDI performance.
This may mean you are using a linux system with the kernel timer resolution set too low. Please contact your Linux distributor for more information. OK

'Linux distributor' ?? Yeah - sure ..
To reveal the resolutions of the available sequencer timers, I tried..

:/# cat /proc/asound/timers
G0: system timer : 4000.000us (10000000 ticks)
G1: RTC timer : 976.562us (100000000 ticks)
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
P0-1-1: PCM capture 0-1-1 : SLAVE
P0-2-0: PCM playback 0-2-0 : SLAVE
:/#

Then, we start Rosegarden, and try to find which timer is involved..

:/# cat /proc/asound/seq/timer
Timer for queue 0 : system timer
  Period time : 0.004000000
  Skew : 65536 / 65536
:/#

A good result for the first test would have been:

G0: system timer : 1000.000us (10000000 ticks)

and for the second test, it would have been nice to see:

Timer for queue 0 : system timer
   Period time : 0.001000000
   Skew : 65536 / 65536

Instead, the 0.004, (ie. 4000 microseconds), means we have a 250Hz kernel timer. Thanks to Chris Cannam for his info on how to do this.

So we get to the stuff I would love to know..
How do we change the timer?
If we do, can we reduce the impact on desktop response?
Can we reduce the number of things needing high frequency attention?
Does this involve a kernel re-compile?
How do we even know if 'pre-emption' is active, or its settings?

Do I need a faster computer? (silly question! ) but anyway, there is a Windows computer not far from here, very much older and slower, that does not choke on audio apps, even the huge and beautiful edit suites.

Should I try Gnome? Is one of the 'lightweight desktops like Xfce or Fluxbox the way to give these applications the processor access they need without making the desktop response sluggish?

[dbdavis]

The timer resolution is a kernel variable set at build time - if you configure your kernel with "make menuconfig", you can find the option under "Processor type and features..."

[Gtrax]

Thanks dbdavis. I found it finally.

Doing the fun of 'make menuconfig' is OK for source-based distros, and those where you can fetch the kernel sources that were maybe tweaked and patched for a particular distro.

For me, the trick is to learn not to get tempted to 'adjust' too many of the other kernel goodies at the same time.