High resolution timer

Timer module

This module uses the RTC as a source of interrupts to provide a ALSA timer. It is a separate module and so its use is totally optional. It registers itself as a timer and when the sequencer is opened the timer is available for use.

I am running it at 1024Hz to give just under 1ms resolution. Its possible to go up to 8kHz.

Building the module

Updated 10 Sep 1999: Builds with the latest ALSA CVS releases.

  1. First make sure that you have not got the RTC driver built into your kernel. If you have then you will need to re-build without it.
  2. Get the source hires-0.3.0.tar.gz and unpack it into the alsa-driver directory. It includes the code for the module and a Makefile.timer file that can be used to build it, or you can add the relevant line to the main makefile should you desire.
  3. Type make -f Makefile timer in the kernel directory.

If you wish download this test program that uses the alsa-lib interface to the timer.

Using the module

If the module is not installed, then nothing is changed everything should work as before.

You should add the following entries to your conf.modules file.

options snd-timer snd_timer_limit=5
options snd-seq snd_seq_default_timer_resolution=1000 snd_seq_default_timer=1

To install the module, as root in the directory kernel :

insmod snd-rtctimer.o

Now when the sequencer is opened, the new timer will be selected, (if you have hardware timers on your system, they may get selected first). The sequencer should now be using the high resolution timer. You can check by looking at /proc/asound/seq/timerand /proc/asound/timers. It will now remove properly and clean up after itself.

rmmod snd-rtctimer

Issues

  1. The motivation for this module was to provide generation of midi clock messages with less jitter than is possible with a 100Hz clock and in the absence of an audio stream to sync with and was inspired by discussion between Frank Van de Pol, Fred Floberg and Michael Ashton in the mailing list.
  2. You might not want to use it if a suitable clock was available from a PCM stream, and this requires better methods of selecting a timing source. Not just by resolution, which is not the only concern, but by other capabilities as well. Perhaps they could be selected by name. A user of the sequencer could request a list of timers and their capabilities and select the best one that was suited its requirements. You may even want to change timing source during a session.
  3. It probably shouldn't run the callback directly out of the interrupt routine. This would cause mis-timing if the callback took longer than a clock tick to execute (or worse).
  4. There is the interaction with setting the date to keep in mind. If you are synchronizing to an external clock with NTP etc., then the RTC is reprogrammed every 11 minutes or so and this will interfere. If you don't run NTP then you should be OK, but its something to look out for in case.
  5. What is the long term accuracy of the interrupts.

Bugs

Probably, but not as many as there were in the first version.