[LAD] [Jack-Devel] How is the TSC calibration accuracy on dual core 2 computers? (And what about HPET?)
Kjetil S. Matheussen
k.s.matheussen at notam02.no
Wed Apr 29 10:19:20 UTC 2009
On Tue, 28 Apr 2009, Jussi Laako wrote:
> Kjetil S. Matheussen wrote:
>> 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.
Thanks! I'll look closer at the jack code.
>> 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.
It shows hpet.
> 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
More information about the Linux-audio-dev