8 Nov
2011
8 Nov
'11
12:45 a.m.
2011/11/6 Paul Davis <paul(a)linuxaudiosystems.com>om>:
On Sun, Nov 6, 2011 at 2:20 AM, Emanuel Rumpf
<xbran(a)web.de> wrote:
Thanks for the hint, Paul, and to Fons of course.
An interresting paper, found it here:
http://kokkinizita.linuxaudio.org/papers/index.html
Still, I wonder:
Why not compute the time of any sample - relative - to a random start
time (using sample frequency) ?
( The start time would be the time, a recording or playback was started. )
For example:
At f = 48000 Hz, I would expect a soundcard to deliver exactly 48000 *
10 = 48E4 samples in 10 seconds.
Is this assumtion wrong ?
If this applied, one could easily calculate the time-position of
Sample S = 96000
based on a random start time (offset) T0 = 10 seconds:
(We know the answer : 10 sec + 2 sec = 12 sec )
Calculation:
1 sec / 48000 Hz * 96000 + 10 sec = 12 sec
(position of sample nr. 96000)
--
E.R.
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.