[LAD] Strange inconsistency in jack frame time

Hello all,

While putting the finishing touches on zita-njbridge and doing a lot
of testing I stumbled on this strange behaviour of jack's frame time.

Let F(i) be the frame time corresponding to the start of period 'i',
and U(i) the corresponding microseconds time.

If jack for whatever reason skips some periods, then one would
expect the difference of F(i) and U(i) to be consistent. They
are in some but not in all cases.

This is the output from a test. When the frame time makes an
unexpected jump, it prints the difference of F, the difference
in U converted to frames, and the difference of these two.
Period size is 256 frames.

dframes = 768 769.0 1.0
dframes = 1024 1322.8 298.8
dframes = 1024 1024.7 0.7
dframes = 768 1067.3 299.3
dframes = 1024 1023.7 -0.3
dframes = 768 1068.5 300.5
dframes = 768 769.2 1.2
dframes = 768 1067.3 299.3
dframes = 1024 1023.9 -0.1
dframes = 1024 1323.1 299.1
dframes = 768 768.2 0.2
dframes = 768 1066.7 298.7

The cases where F and U match are due to starting another client
(designed to be 'heavy'), those where F and U do not match occur
when the same client is terminated (using ^C). The error for
those is consistently a full period plus around 4333 frames.

So it seems that the frame time is not a reliable method to
determine how many frames have been lost.

Using jack1, 0.124.1

Ciao,

-- 
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev