Bug 17: 'Received' timestamp from within 'process()' and use 'off_start' for each packet.

[mungewell]

Bug #17 Improves the accuracy of the 'Received' timestamps when using SHM to NTP/Chrony.

[x42]

Keep in mind that the jack process callback will be called at some undefined time each cycle.

the time returned by gettimeofday will jitter by the period-size. -- you could try to correct this by using jack_frames_since_cycle_start or use jack's time API instead: https://jackaudio.org/api/group__TimeFunctions.html

[mungewell]

Interesting.

I had looked at 'jack_last_frame_time()' before but rejected as the relationship between sample clock and system clock was unknown... and perhaps convoluted by the fact that Chrony was pulling the system clock around.

The plot seems to show that gettimeofday() is reporting consistantly (on a mostly idle system). But I'll experiment blending jack_frames_since_cycle_start() to gettimeofday() and report whether it improves situation....

I also noticed that the buffer length is quite small (1024 bytes) meaning that there are only a couple of LTC packets in each cycle. An interesting experiment would be to use a larger buffer (at the cost of latency) but then see if closely coupled LTC packets show the same jittering - ie. implying that the problem lies outside of LibLTC.

[dimitry-ishenko]

@x42 this is superseded by PR #25.

Few notes:

• https://github.com/x42/ltc-tools/pull/18/commits/945271687f89d6d638f11ec447cc172bb89cf6dd I agree with moving "received time" computation into process() as this is when the timecode is received and what the NTP server needs to know. This eliminates jitter associated with mutex and condition variable locking/unlocking.
  
  However, this seems a bit over engineered and requires back and forth conversions. In my PR I've simply moved tv_recv computation into process().

• https://github.com/x42/ltc-tools/pull/18/commits/28946cc01d663106dacb9860dae8075465e111a6 When we receive a TC frame is there a guarantee that the TC value it contains is associated with its start time (when it started to be generated) and not its end time (when it's done being generated and is fully received by us)? In other words, do we know for sure that the LTC source is not already offsetting it for us?

[x42]

Superseded by PR #25.