streamの遅延時間について

[nakky]

質問させて頂きます。
現在、HarkDataStreamSenderにて、分離した音源をTCPで受信して抽出しております。設計上HARK内ではどれくらいの遅延（TAMAGOマイクに入力した音声をTCPで送信するまで）が想定されますでしょうか。また、VAD情報データ（音声の開始と終了など）をネットワーク外で抽出することはできませんでしょうか。よろしくお願い致します。

[nakky]

度々失礼致します。追加で質問ですが、HarkDataStreamSenderから送られるタイムスタンプは、いつのものでしょうか。TCPソケットで送信開始丁度のスタンプとなりますでしょうか。
よろしくお願い致します。

[Masayuki Takigahira]

お問い合わせありがとうございます。

遅延量について：
ご利用になるノード(及びパラメータの値)の組み合わせにより遅延量は変化します。

例えば、平滑化を行うノードでは複数フレームのデータを必要とします。
50フレーム(1フレーム=10msとした時、500ms)で平滑化を掛けた場合には
50フレームバッファするという事ですので500ms分の遅延が発生します。
パラメータで10フレーム分の平滑化に設定を変更すると100msになります。
また、FFTを例に挙げるとサンプリング周波数16kHzのデータを512サンプル
のウィンドウ幅で処理する場合には約32ms(16000/512)の遅延があるという
事になります。
つまり、ユーザが設定されたネットワークによって遅延量が決定しますので
設計上の遅延というものは定めていません。
一方で、オンラインで処理が可能であると謳っているノードについては
推奨スペックの環境でノードを初期パラメータのまま使用する条件において
1フレーム分の処理を1フレーム以内に終える事が出来る仕様です。
各ノードの遅延量の合計に1フレームの時間を加えた時間が総遅延量となります。

遅延量の測定方法について(タイムスタンプの処理について)：
現在、分離音を送信しているHarkDataStreamSenderノードの”TIEMSTAMP”
端子は何も接続していない状態としてください。
何も接続していない場合は、ヘッダ送信(TCPソケットへwriteを開始する)
直前のタイムスタンプが入ります。
また、AudioStreamFromMicの出力端子として”TIMESTAMP”(すべて大文字)
を追加して頂き、もう一つHarkDataStreamSenderノードを追加した上で
“TIMESTAMP”端子に接続してください。
“TIMESTAMP”端子に接続がある場合、接続したノード(音響信号入力ノード)
から送られたタイムスタンプが入ります。
2つのタイムスタンプの差分を取る事で遅延量を測定する事が可能です。

VAD情報について：
分離処理をされているとの事ですが、LocalizeMUSICによって定位処理を
行った場合には定位している区間(HDH_SrcInfoでsrc_idの出現から消失まで)
が有音区間(発話区間)となります。
SourceTrackerやSourceIntervalExtender等から出力されるSource情報を
HarkDataStreamSenderの”SRC_INFO”端子に接続されているかと存じますが
分離音と共に得られていませんでしょうか。

https://www.hark.jp/document/hark-document-ja/subsec-HarkDataStreamSender.html
より、”HDH_SrcInfo”の項目をご参照ください。

また、マイクアレイの収録時刻と同期して発話開始時刻、発話終了時刻を得たい
ということでしたら遅延量測定のところで記載したようにAudioStreamFromMic
に”TIMESTAMP”端子を追加し、HarkDataStreamSenderに接続する事で実現可能です。

あるいは、ネットワークの外でVADを行って区間抽出したいという要望でしたら
分離方向が既知であれば、ConstantLocalizationノードを用いる事で
常に指定した音源方向で分離したストリームを送信し続ける事が可能です。

以上、宜しくお願い致します。

[橋口夏樹]

ご回答ありがとうございました。
添付のようなノードで、LENGTH 512（samples）、Fs=16kHz、1フレームあたり32msで、MultiFFTの
WINDOW_LENGTHで32ms、LocalizeMUSICのWINDOWで50frames（1.6s）で合計約2秒ほど遅延することになるかと思いますが、考え方はあっておりますでしょうか。（実際はそこまで遅延しているようには思えません）

AudioStreamFromMicからのTIMESTAMP端子の接続方法でうまくいかないのですが、
他にSRC_INFOを接続したりするのでしょうか。また、documentにはTIMESTAMPの信号情報が載っておりませんが、どこかに書かれておりますでしょうか。2つのHarkDataStreamSenderを、たとえば両方Localhost,別ポート選択で後の設定は同じで良いでしょうか。

VAD情報については、IDの発生と終了時刻は取得できておりますが、同時に取得した分離音は、
前後に余裕を持った（前後に無音（に近い）が入っている）ものとなっていると思われ、”発話区間”ではないと思われますがいかがでしょうか。

質問が立て続けで申し訳ありません。
よろしくお願い致します。

Attachments:

1. 

   .jpg
   

[Masayuki Takigahira]

すみません。段落を付けていませんでしたので混乱させてしまいました。
イメージ画像を添付いたしましたのでご確認下さい。
2019/04/02 14:50:00 追記：
　添付イメージに誤りがありましたのでframes_revised.pngとして再アップロードしました。
　旧イメージのframes.pngは記録のために残してありますが、誤りを含んでいます。

言葉で説明すると次のようになります。
１．HARKではFFTのようにWindow処理を行うノードがありますのでWindow幅でバッファする必要があります。そのため、16kHzサンプリングでWindows幅(LENGTHと呼ばれるパラメータ)に512サンプルと設定した場合、約32ms固定で入力が遅延します。これはネットワークがどのように接続されていても固定です。
２．シフト量(ADVANCEと呼ばれているパラメータ)で160サンプルと設定した場合、1frameは10msとなりますので各ノードは10ms間隔でデータを受け取ります。
３．ノードによって、複数フレームをバッファする事があります。LocalizeMUSICなどがその例です。WINDOWで50と設定すると50フレーム得られてから計算を開始します。各ノードはストリームで処理されますので、ノードの中で最も大きなフレーム数だけを考慮します。
４．各ノードでは計算時間のため遅延が発生しますが、オンライン処理が可能なものは1フレーム以内に計算を終えます。そのため、追加の遅延時間として1フレーム(10ms)分だけ考慮します。

そのため、お使いのネットワークファイルでは32ms+500400ms+10msで540440msぐらいと思われます。

—-

> AudioStreamFromMicからのTIMESTAMP端子の接続方法でうまくいかないのですが、

LocalizeMUSICの項目に端子の追加方法について掲載しておりますので、
以下の方法と同じ手順でAudioStreamFromMicにTIMESTAMPという名称の出力端子を
追加してください。
https://www.hark.jp/document/hark-document-ja/subsec-LocalizeMUSIC.html

> documentにはTIMESTAMPの信号情報が載っておりませんが、

すみません。AudioStreamFromMicのTIMESTAMP端子についての情報がdocumentに記載されていませんでした。今後のメンテナンスの際に追記させて頂きます。

• This reply was modified 5 years, 8 months ago by Masayuki Takigahira.
• This reply was modified 5 years, 8 months ago by Masayuki Takigahira.

Attachments:

1. 

   frames.png
   

2. 

   frames_revised.png
   

[橋口夏樹]

ありがとうございました。何度も申し訳ありませんが、以下質問させて下さい。

頂いた図に関して
1.そもそもですが、Frame1とFrame2の重複している部分は同波形データで、少しづつシフトしながら演算をしているという事でしょうか。
2.Output delayの計算式のBuffer部分ですが、max(number_of_frames)-1(例でいうと、5-1=4frames)になりませんでしょうか。
3.バッファを考慮するフレームはノードの中で最も大きなフレーム数という事で理解しましたが、その際SpirceTrackerの後段に出てくるSourceIntervalExtenderに設定している50framesもLocalizeMusicのwindowと同数であるため、特段考慮（追加）しなくて良いという考えでしょうか。
4.TIMESTAMP端子についてですが、端子の追加方法は分かりましたが、添付のようなネットワークで実行すると、下記のようなエラーが出て止まってしまいます。
どの様にすればよいか助言頂けますでしょうか。
・
・
・
time: 50,
time: 51,
time: 52,
time: 53,
send header 12: 0.
SRC_NUM: 0
PKN2FD6BufferE error: trying to read non-existing element.
Element 0
Buffer is:
<Buffer
< 99 <TimeStamp <sec 1554204444> <usec 872533> > >
C:\work\flowdesigner-0.9.1-hark\data-flow\src\BufferedNode.cc line 126: Node node_AudioStreamFromMic_1 (type 18AudioStreamFromMic) Exception caught in BufferedNode::getOutput
C:\work\HARK-Windows\hark-fd\src\HarkDataStreamSender.cc line 975: Node node_HarkDataStreamSender_2 (type 20HarkDataStreamSender) Exception caught in BufferedNode::getOutput
C:\work\flowdesigner-0.9.1-hark\data-flow\src\Collector.cc line 83: Node ALL_NETWORK_OUTPUTS (type N2FD9CollectorE) Exception caught in Collector::getOutput
C:\work\flowdesigner-0.9.1-hark\data-flow\src\Iterator.cc line 118: Node node_LOOP0_1 (type N2FD8IteratorE) Error in Iterator::getOutput
C:\work\flowdesigner-0.9.1-hark\data-flow\src\Collector.cc line 83: Node ALL_NETWORK_OUTPUTS (type N2FD9CollectorE) Exception caught in Collector::getOutput

5.先に質問させて頂きましたVAD情報に関する発話区間の考えについてはいかがでしょうか。

何度も申し訳ありません。よろしくお願い致します。

Attachments:

1. 

   _timetest.jpg
   

[Masayuki Takigahira]

「1．」について
はい。入力された音響信号の重複部分は同じデータとなります。入力信号のシフト量とウィンドウ幅を独立で設定出来るように設計されています。

「2．」について
すみません。おっしゃる通り -1 を行うのが正しいです。

「3．」について
はい。どちらのノードもバッファで以前のフレームのデータを保持しており、50フレーム目を受信してから処理が開始できるという事ですのでネットワーク全体で1回だけ考慮するだけで済みます。

「4．」について
ネットワークのスクリーンショットを拝見する限りでは特に問題が無く見えましたので、こちらでも再現確認をさせて頂きます。そのため、少々お時間を頂けますでしょうか。
また、エラー出力の内容からHARK2.xと思われますが、HARKのバージョンを確認させて頂いても宜しいでしょうか。

「5．」について
すみません。前回、見落としていたようです。
> 前後に余裕を持った（前後に無音（に近い）が入っている）ものとなっていると思われ、
> ”発話区間”ではないと思われますがいかがでしょうか。
SourceTrackerのPAUSE_LENGTHとSourceIntervalExtenderのPREROLL_LENGTHにより前後に余裕が出ています。もし、前後の無音区間を無くしたいという事でしたらパラメータを調整して頂く必要があります。SourceTrackerのPAUSE_LENGTHについては短くしすぎると長文を発話している場合などにショートポーズ(息継ぎや句読点)の位置で定位結果が分割されることがありますのでご注意ください。
下記URLにノードの説明が御座います。音声認識が目的の場合、認識エンジンによっては(特に前半部の)無音区間が無い場合に性能(認識率)が低下する事が御座いますのでご注意ください。また、後半の無音区間については無音に見えても(例えば「センター」の「ー」の部分などの)音素や残響などが含まれているケースがありますので短く設定されたい場合はそのような点もご考慮の上でご設定ください。
https://www.hark.jp/document/hark-document-ja/subsec-SourceTracker.html
https://www.hark.jp/document/hark-document-ja/subsec-SourceIntervalExtender.html

以上、宜しくお願い致します。

• This reply was modified 5 years, 8 months ago by Masayuki Takigahira.
• This reply was modified 5 years, 8 months ago by Masayuki Takigahira.

[橋口夏樹]

早急にご回答いただきありがとうございました。
1～3,5に関して承知致しました。
4についてですが、HARK2.5です。HARK3.0が出た当初に色々と動かしてみたところ、
bufferOverflowとなることがあり、とりあえず旧verで試していた次第です。

よろしくお願い致します。

[橋口夏樹]

失礼致しました。ver2.4でした。
HARK 2.4.1
HARK-SSS 2.4.0

[Masayuki Takigahira]

原因が判明いたしましたのでご連絡させて頂きます。

「4．」について
スクリーンショットで右側に配置されたHarkDataStreamSenderのSRC_INFO端子の入力ですが、SourceIntervalExtenderの出力端子から接続する必要があります。

SRC_WAVE、SRC_FFT、SRC_FEATURE、SRC_RELIABILITYの各入力端子を使用する場合、SRC_INFOはそれらの計算に用いたSource情報である必要があります。
右側のHarkDataStreamSenderでSRC_WAVE端子に入力されている分離音はGHDSSでSourceIntervalExtenderのSource情報によって分離されています。そのため、SourceIntervalExtenderの出力をSRC_INFO端子へ接続する必要があります。
左側のHarkDataStreamSenderは上記に挙げた4入力(SRC_WAVE、SRC_FFT、SRC_FEATURE、SRC_RELIABILITY)を使用していませんのでSourceTrackerとSourceIntervalExtenderどちらの出力をSRC_INFOに入力しても動作します。ただし、SourceIntervalExtenderを通していないため定位区間の結果は変わります。

SourceIntervalExtenderは定位区間を前方に拡張していますので、お使いのネットワークではSRC_WAVEの入力はあるがSRC_INFOの入力が無いという状態が右側のHarkDataStreamSenderで発生しています。そのため、ソケットから送信するデータ構造が作れないためエラーとなっております。

以上、ご確認のほどよろしくお願いします。

[橋口夏樹]

ありがとうございました。
右側のHarkDataStreamSender(node_HarkDataStreamSender_1)のSRC_INFOの入力をSourceIntervalExtenderの出力に変更しましたが、同じエラーが出てしまいました。
エラーコードを見る限り、エラーは左側のHarkDataStreamSender(node_HarkDataStreamSender_2)に対して出ていると思われますが、いかがでしょうか。

よろしくお願い致します。

Attachments:

1. 

   _timetest2.jpg
   

[Masayuki Takigahira]

ほぼ同じ構成のネットワークファイルを準備し、再現試験を行っておりますが現時点では再現出来ておりません。同じバージョンのHARKを準備して確認しておりますが問題なく動作しており、HARKのバージョンによる問題ではないようです。

問題が発生した環境はUbuntuとWindowsのどちらの環境でお使いになられていますでしょうか。現在、Ubuntu環境で再現確認を行っております。再現確認を行った環境を添付させて頂きました。添付ファイルをダウンロードして頂き、次の手順を行う事で私がテストした環境と同じ構成の環境を構築する事が可能です。もし、問題が起きないようでしたらネットワークファイルの違いを比較する事で原因が判明するかもしれません。
“tcp_serve.py”のスクリプトはHarkDataStreamSenderから送信したデータを受信するためのダミーのTCPサーバで受信したデータは処理せず破棄しています。TCPサーバの終了方法は”Ctrl+C”になります。また、ネットワークファイルはTAMAGOがplughw:1,0に接続された環境で動作します。”arecord -l”を実行した際に確認できる、デバイス番号が異なる場合はAudioStreamFromMicのパラメータを変更する必要があります。(以前の書き込み内容からTAMAGOを所持されている前提で書かせて頂きました。)

mkdir workspace
cd workspace
wget https://www.hark.jp/networks/HARK_recog_2.3.0.1_practice2.zip
unzip HARK_recog_2.3.0.1_practice2.zip
cd HARK_recog_2.3.0.1_practice2
cp <download_path>/time_test.tar.gz ./
tar -zxvf time_test.tar.gz
python3 ./tcp_server.py

tcp_server.pyを起動した後で、別のTerminal上で
batchflow ./time_diff.n

上記テストで問題が起きず、お使いのネットワークファイルだけ問題が起きる状況が改善できなかった場合、差し支えなければで宜しいのですが、お使いのネットワークファイル等を頂くことは可能でしょうか。再現しないためファイルを頂かなければこれ以上の解析は困難な状況です。
本フォーラムページではファイルサイズが512KB以内であれば最大4ファイルまで同時に添付する事が可能です。

以上、宜しくお願い致します。

Attachments:

1. time_test.tar.gz

[nakky]

ありがとうございました。
windowsの環境で試しておりました。

教えて頂いた環境でubuntuにて試したところ、問題なく動きました。また、当方が作成していたネットワークでも問題なく動きましたが、やはりwindowsだと前記のエラーが出るようです。

なお、頂いたサーバファイルのコメントをアンコメントしてprintされたデータの、どこをどう比較すれば良いか教えて頂いても良いでしょうか。出力結果（txt）を添付致します。
何度も申し訳ありません…。
よろしくお願い致します。

Attachments:

1. jissoku.txt

[Masayuki Takigahira]

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版で対応して頂けると助かります。

• This reply was modified 5 years, 8 months ago by Masayuki Takigahira.

[橋口夏樹]

詳細教えて頂き誠にありがとうございました。
全てクリアになりました。

この度は何度もご対応頂き大変感謝申し上げます。
今後ともよろしくお願い致します。

[Author]

Posts