Subject: Re: [linux-audio-dev] best method for timing
From: Tim Goetze (tim_AT_quitte.de)
Date: Wed Apr 17 2002 - 14:41:16 EEST
Nick D wrote:
>On Tue, 16 Apr 2002 19:08:23 -0400
>Paul Davis <pbd_AT_Op.Net> wrote:
>
>> >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.
>>
>> the assumption in the code i posted is that the RTC is used only to
>> provide a tick with reasonable periodicity and adequate
>> resolution. the actual "current" time can only be determined by
>> looking at the transport system in ardour, since we are talking about
>> musical/audio time, not wall clock time.
>
>/dev/rtc also tells us how many interrupts there were since the
>last read, is this not reliable enough? i assume this value will
>always be correct?
the kernel is designed never to completely drop interrupts even if
they cannot be processed in due time.
if you're only doing sequencing, you can safely use the number of
interrupts reported to calculate the time passed. however i think
it's more flexible to use another means of getting the current time
and just use the rtc as a simple pulse generator like paul described.
most platforms provide a microsecond-resolution in gettimeofday(2) by
evaluating the cycle counter if one is present[*]. this saves you
#including <asm/*.h> and other dirty code if you can afford to have
the small syscall overhead, and i think you can in a sequencer clock.
tim
[*] /usr/src/linux/arch/<target-architecture>/kernel/time.c,
function do_gettimeofday()
This archive was generated by hypermail 2b28 : Wed Apr 17 2002 - 14:29:13 EEST