- This topic has 14 replies, 3 voices, and was last updated 5 years, 7 months ago by
.
-
ご回答ありがとうございました。
添付のようなノードで、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:
すみません。段落を付けていませんでしたので混乱させてしまいました。
イメージ画像を添付いたしましたのでご確認下さい。
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, 7 months ago by
.
-
This reply was modified 5 years, 7 months ago by
Attachments:
ありがとうございました。何度も申し訳ありませんが、以下質問させて下さい。
頂いた図に関して
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::getOutput5.先に質問させて頂きましたVAD情報に関する発話区間の考えについてはいかがでしょうか。
何度も申し訳ありません。よろしくお願い致します。
Attachments:
「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以上、宜しくお願い致します。
ありがとうございました。
右側のHarkDataStreamSender(node_HarkDataStreamSender_1)のSRC_INFOの入力をSourceIntervalExtenderの出力に変更しましたが、同じエラーが出てしまいました。
エラーコードを見る限り、エラーは左側のHarkDataStreamSender(node_HarkDataStreamSender_2)に対して出ていると思われますが、いかがでしょうか。よろしくお願い致します。
Attachments:
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版で対応して頂けると助かります。
- You must be logged in to reply to this topic.