29 Apr
2009
29 Apr
'09
8:19 a.m.
On Tue, 28 Apr 2009, Jussi Laako wrote:
It shows hpet.
Kjetil S. Matheussen wrote:
Thanks! I'll look closer at the jack code.
I've looked at the HPET code in jack, but am unsure how accurate it is,
and whether there are any overhead using it?
Resolution on my machine is 1 / 14.318180 MHz. Frequency can vary
typically from 12 to 16 MHz. Access is usually rather fast through MMIO.
Accuracy can vary depending on hardware and environment, same applies
even more for TSC.
that's the
accuracy of usleep(). So it looks promising, but
I need at least 0.1ms accuracy...
In my opinion, clock_gettime() with CLOCK_MONOTONIC is pretty good if
kernel is using reasonably good clock source. You can check the current
one by "cat
/sys/devices/system/clocksource/clocksource0/current_clocksource". Over
rather long periods, CLOCK_REALTIME with good NTP sync would probably be
a good choice.
Over what time span you would need that 0.1 ms
accuracy?
Hard to say. This is for testing a couple of garbage collectors, and the
difference between worst case and best case can be quite high.
Worst-case is probably around 1ms, and best case maybe around 0.1ms.
It also depends on buffer settings, so I can use higher buffers
to get higher timings.
But calls to clock_gettime()/HPET/etc. will only happen maximum 6 times
per audio block, so clock_gettime()/HPET/etc. doesn't have to be extremely
efficient.