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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
