[Jack-Devel] DLL not re-initialised after freewheeling

PrevNext  Index
DateThu, 15 Mar 2012 22:59:26 +0000
From Fons Adriaensen <[hidden] at linuxaudio dot org>
ToJack Developers <[hidden] at lists dot jackaudio dot org>
Follow-UpStéphane Letz Re: [Jack-Devel] DLL not re-initialised after freewheeling
Hello all,

Following up my previous post, here is some hard evidence. It's
the output of a small test program written to show the problem.

# Two values are printed in each process callback. The first one is
# jack_last_frame_time() converted to usecs using jack_frames_to_time(),
# in other words the DLL's estimate of the start of the current cycle.
# The second is the current usecs time. Both are converted to seconds,
# and the integer part of the first reading is substracted to get
# more readable values. This is the actual code:
#
# int jack_callback (jack_nframes_t nframes, void *arg)
# {
#      jack_nframes_t  ft1;
#      double          tj1, tj2;
#
#      if (freewheeling) return 0; // set by freewheeling callback.
#
#      ft1 = jack_last_frame_time (jack_handle);
#      tj1 = 1e-6 * (jack_frames_to_time (jack_handle, ft1));
#      tj2 = 1e-6 * jack_get_time ();
#
#      if (offset == 0) offset = (int) tj1;
#      tj1 -= offset;
#      tj2 -= offset;
#      printf ("%10.6lf %10.6lf\n", tj1, tj2);
#
#      return 0;
#  }
#
#
# The listing starts about 4 seconds after the program is started.
# As expected the two values are near equal, with the current time
# around 1 ms after the cycle start time.
------------------------------
  4.052306   4.052380
  4.057639   4.057715
  4.062972   4.063046
  4.068305   4.068377
  4.073637   4.073710
  4.078970   4.079099
  4.084303   4.084403
  4.089636   4.089733
  4.094969   4.095050
  4.100302   4.100384
  4.105635   4.105753
  4.110968   4.111071
------------------------------
# At this point Jack is put in freewheeling mode for 11 seconds.
# Output resumes when freewheeling mode is terminated.
# One would expect the wakeup time to be around 15 seconds or so
# (the time actually returned by the usecs timer). But since the
# next_wakeup time is not re-initialised after freewheeling, the DLL
# continues with the time when freewheeling was started. Since it
# sees a giant error of 11 seconds, it tries to catch up by increasing
# the apparent period time, up to 120 ms in this case. The DLL recovers
# after about 10 seconds, but until then it provides completely bogus
# information.
------------------------------
  4.116301  15.334817
  4.234378  15.340120
  4.351883  15.345446
  4.468816  15.350789
  4.585177  15.356115
  4.700967  15.361449
  4.816185  15.366783
  4.930832  15.372110
  5.044908  15.377443
  5.158413  15.382776
  5.271347  15.388105
  5.383711  15.393443
  5.495505  15.398775
  5.606730  15.404106
  5.717386  15.409438
  5.827473  15.414774
  5.936992  15.420106
# Etc.
# Both values converge after about 10 seconds.

Ciao,

-- 
FA

Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
PrevNext  Index

1331852380.1480_0.ltw:2,a <20120315225926.GA19272 at linuxaudio dot org>