Subject: Re: [linux-audio-dev] best method for timing
From: Nick D (nixx_AT_nixx.org.uk)
Date: Wed Apr 17 2002 - 16:25:16 EEST
On Wed, 17 Apr 2002 13:41:16 +0200 (CEST)
Tim Goetze <tim_AT_quitte.de> wrote:
> 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.
For a simple applications i just thought it would be conceptually simpler to work uniquely off the interrupt. I mean, say we missed an interrupt somehow (they got built up under load) and so missed an event we wanted to trigger, then theres not really much we can do about it anyways...
> 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.
Yes, i suppose the overhead for gettimeofday() is really a non-issue.
cheers,
nick
This archive was generated by hypermail 2b28 : Wed Apr 17 2002 - 15:10:51 EEST