At Mon, 17 Sep 2001 18:23:52 -0600,
Jack Moffitt wrote:
>
> > Isn't it in nanoseconds (1e-9)?
> > If so, the following drift will be 1/1000...
>
> Yes. But reading through more code, we're also losing 2/3 of a
> nanosecond in tick resolution:
>
> tick->resolution = (tempo * 1000) / ppq;
>
> Which means we're losing about 1.25 nanoseconds every period.
>
> I can definately hear the drift. So it _must_ be drifting more that
> .5ms over 5 minutes. I'm still searching for other places where we're
> losing precision.
My reckless math try (it's too late now, though :)
X = real interrupt period, x = truncated in nsecs
X = x + a
Y = real tick duration Y, y = truncated in nsecs
Y = y + b
where a and b are fractions.
X = period_size * 1e9 / freq
Y = tempo * 1e3 / ppq
Thus expected tick drifts during t seconds are
D = (freq * t / period) * (Y / X - y / x)
= (freq * t / period) * ((y + b) / (x + a) - y / x)
bx - ay
= (freq * t / period) * ------------
x (x + a)
Now, freq = 44100, t = 5 * 60, period = 32, tempo = 500000,
ppq = 480
x = 725623, a = .58276643
y = 1041666, b = .66666666
and got
D = .1 msec
So, it's still too short.
In theorecially maximum case:
max D = (freq * t / pepriod) * max(x, y) / x^2
max D = .851 msec
This looks reasonable?
Takashi
>
> jack.
>
> _______________________________________________
> Alsa-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
