Re: [LAD] [Jack-Devel] How is the TSC calibration accuracy on dual core 2 computers? (And what about HPET?)

From: Kjetil S. Matheussen <k.s.matheussen@email-addr-hidden>
Date: Wed Apr 29 2009 - 13:19:20 EEST

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
efficient.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Apr 29 16:15:03 2009

This archive was generated by hypermail 2.1.8 : Wed Apr 29 2009 - 16:15:03 EEST