6 Nov
2011
6 Nov
'11
2:10 p.m.
On Sun, Nov 6, 2011 at 2:20 AM, Emanuel Rumpf <xbran(a)web.de> wrote:
2011/11/5 Iain Duncan
<iainduncanlists(a)gmail.com>om>:
the clock used for the system clock is less important than using a DLL
to "link" the audio clock and the system clock. this enables you to
answer the question "if its time T on clock1, what time is it on
clock2?"
fons wrote the canonical paper on this for a Linux Audio conference a
few years ago, and JACK contains a DLL for this purpose
(jack_get_microseconds() will return a prediction of the current time
according to the audio clock, based on the system clock and the DLL.
On Thu, Nov 3, 2011 at 8:05 PM, David Robillard
<d(a)drobilla.net> wrote:
I think frame time (a frame of samples) is
meant here ? That time is
delivered in the jackd process callback.
The only difference non-jack would make is you need some function to
tell you roughly what audio time it is you can call from another thread.
Does one use the system clock for that? Is it accurate enough?
Depends on the
system clock used, I presume.
For best accuracy, you have to configure your kernel to support HPET
(high precision event) timers
and make ALSA use it as default.