Open bquandt opened 11 years ago
I quantified it to delay = zero (after applying proper jack latency compensation only using jack_iodelay) but the overall clock jitter is on the order of a 1-2 msec !! likely due to the bad clock / freq stability in the mk802.
to measure this. Feed the same LTC audio-signal into both ALP and CLP. jltcdump will print
[SMPTE] [monotonic audio-frame] [system-time]
comparing the files from both machines allows to measure clock accuracy.
Also on CLP: sudo /etc/init.d/ptpd stop; sudo ptpd -d -c -g
will print launch PTPd (in slave only mode) and print stats.
I don't know where we might be recording our ptp sync information, in relation to our ltc start/stop values.
Basic issue is to record our confidence on our ptp in relation to the timestampes of ltc/rs. So we can possibly adjust our ltc/rs values for drift if/when cpop is disconnected from the network.
Minmally, I'd want the ability to determine how far off we were, but ideally, I'd love a means to both report the error, plus correct the recorded ltc/rs values back into time alignment from our master clock.
Let's assume we have Real-time clocks on all appliances on the network (ie cpop on mk802 will have a RTC which does not reset back to 0:00:00 upon power loss).