2つのHarkDataStreamSenderが送信する構造体のHD_Headerに含まれるtv_secとtv_usecに入る値を比較します。片方はAudioStreamFromMicからの(該当フレームのAudio入力時の)タイムスタンプが入っており、もう一方はHarkDataStreamSenderの(該当フレームのSocket送信時の)タイムスタンプが入っております。
HarkDataStreamSenderのプロトコルについては、以前の書き込みで分離音を受信されているとの事でしたので記載しておりませんでしたが下記の仕様で送信されています。
https://www.hark.jp/document/hark-document-ja/subsec-HarkDataStreamSender.html
頂いたデータ(jissoku.txt)によりますと、
4行目のtypeが0x0004、countが0x0003ですのでSRC_INFOのみ接続された左側のHarkDataStreamSenderの3フレーム目となります。
4行目のtv_sec、tv_usecにあたる場所のバイト列が 59 42 a7 5c 00 00 00 00 cc b1 05 00 00 00 00 00 でしたので、 tv_sec=1554465369, tv_usec=373196 (*1)となります。JSTになっているので+9:00されてしまっている事から、tv_secより3600*9を引く必要がありました。
2行目のtypeが0x000c、countが0x0003ですのでSRC_INFOとSRC_WAVEに接続された右側のHarkDataStreamSenderの3フレーム目となります。
2行目のtv_sec、tv_usecにあたる場所のバイト列が ca c3 a6 5c 00 00 00 00 53 f6 02 00 00 00 00 00 でしたので、 tv_sec=1554432970, tv_usec=194131 (*1)となります。
2行目から4行目を引くと、3フレーム目の遅延は 820,935 [us] となります。
各ノードで時間の取得方法に差がありGMTとJSTを比較する事になってしまい、ご面倒をおかけしますが宜しくお願い致します。
2019/04/08 追記1：
後で読み返して説明不足と思いましたので追記させて頂きます。
*1) HARKの通信はドキュメント上で記載がない場合 リトルエンディアン で行っており、 tv_sec および tv_usec は int64_t ですので 64 bits (つまり、8 Bytes)で送られています。頂いたログではpythonのprint関数でASCIIキャラクタに変換されてしまっているものがありましたので、上記では元のHEXバイト列に戻しております。
2019/04/08 追記2：
おっしゃる通りWindows版でのみ問題が起きているようです。Windows版の旧バージョンに対する修正を提供する事が現状困難ですので、Ubuntu版で対応して頂けると助かります。
