Subject: Re: [linux-audio-dev] best method for timing
From: Tim Goetze (tim_AT_quitte.de)
Date: Wed Apr 17 2002 - 00:39:28 EEST
Nick D wrote:
>On Tue, 16 Apr 2002 09:34:21 -0400
>Paul Davis <pbd_AT_Op.Net> wrote:
>
>> >I need to do some timing code - for some basic kind of sequencing..
>> > [..]
>> >What approaches have people used, and how successful were they?
>>
>> poll(2) on /dev/rtc. You will need to be root, or have CAP_RESOURCE,
>> to set the frequency of the clock to a useful value, and you will need
>> to run SCHED_FIFO to not have the kernel scheduler mess things up.
>
>Cool, thanks (and rob!)
>
>A quick aside - should /dev/rtc be user readable?
>On my system (with devfs) its not, i just wondered whether the same was true for other systems?
>
>if i'm not root, i can still set the clock to 64Hz, how bad is that for timing? (not great, i imagine.) say for doing a step sequencer, i think i could get away with that, and use the higer rate if possible.
if you do not want to be restricted to certain bpm settings you need
more than 64 Hz. [the 64 Hz 'safety' limit imposed in the rtc kernel
module is quite absurd if the same uid can legally ask a pcm interface
to interrupt at up in the kHz range, but it's there.]
i think that 1024 Hz are adequate, and 512 are sort of workable, but
not production quality.
if you do not run the timer thread SCHED_FIFO, jitter will be
intolerable imo. so you need to supply uid 0 resources anyway.
>> ardour and softwerk (which doesn't compile right now) both have code
>
>ah, its not just me then ;-)
>
>> for the RTC. In fact, I'll include ardour's below - its very simple
>> really. Any parts that are not clear are almost certainly not
>> necessary :)
one remark on the code paul posted: occasionally interrupts can be
dropped if a higher priority thread is present on your system
(RT audio on a single processor for example); so you cannot just
assume time has advanced by 1 / rtc_frequency seconds per poll
return.
read all about it in /usr/src/linux/Documentation/rtc.txt . in short,
the unsigned long you read from the device file informs you about the
precise number of interrupts that happened if you >>= 8 it.
tim
This archive was generated by hypermail 2b28 : Wed Apr 17 2002 - 00:28:11 EEST