streamの遅延時間について part2

[橋口夏樹]

以前streamの遅延時間について質問した者です。
その節はありがとうございました。
また追加の質問がございます。何度も申し訳ございません。

現在、HARKで抽出した音源から早く応答するべく検討しております。
（区間検出の終わりを早く抽出したい）

以前,Fs=16kHzで
LENGTH(512(32ms))+ADVANCE(160(10ms))*window（50）≒540ms、マイク入力からstrema出力まで遅延を発生するということをお伺いしました。
この辺のADVANCE（やLENGTH）、preroll_length、windowのパラメータを色々と変えて、以前教えて頂いたtime_diff.nで測定してみたところ、添付のような結果となり短縮されているようでした。

現在HARKでビームフォーミングして抽出した音声streamに
、さらに別のvad変換（webrtcvad）をして全体の時間を測定しておりますが、パラメータをいじる（例えばADVANCE=80,winodw=20）とすると、HARK内では時間は短縮されてもトータルの時間は多くかかってしまいました。（定位の精度が落ちたことによるのかなと思います）
時間を短縮しつつ、定位の精度を落としにくいパラメータ設定方法はありますでしょうか。

また、HARKでは各ノードでstream処理しており、はじめに遅延した540msは理論上もそのまま最後まで遅延したままになる思いますが、
実時間処理をしない方法はないのでしょうか。

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

Attachments:

1. diff測定結果.txt

[橋口夏樹]

追加で質問です
・SourceIntervalExtenderに設定しているフレーム数分の時間（advance160でf=16kHzだと10ms×50=500ms）は、以後の処理を遅らせるのだと思いますが、これらを50⇒0に設定するとそれだけ遅延が短い結果となっております。
以前バッファを考慮するフレームはノードで最も大きなフレーム数であり、LocalizeMusicのwindow50であればSourceIntervalExtenderの50frameは追加で時間がかかるものではいと伺ったので、なぜかなと思いましたが、処理系の速度の違いなどによるものでしょうか。
・また、HARKで抽出した音声streamは前後に秒単位で無音がありますが、これらを極力小さくする設定はありませんでしょうか。

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

[Masayuki Takigahira]

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

まず、マイクへの入力から分離音が得られるまでの応答速度改善が主目的のようでしたので
分離音(正確には定位区間)の前後に無音区間が入る理由から説明させて頂きます。

前方の無音区間は、SourceIntervalExtenderノードのPREROLL_LENGTHパラメータの影響です。
https://www.hark.jp/document/hark-document-ja/subsec-SourceIntervalExtender.html
[ノードの詳細]の項に記載しているように、定位区間を遡って設定するための機能ですので
前方フレームのバッファからデータを得る必要があるためノードの処理は遅延します。
SourceTrackerノードで設定するTHRESHより大きなパワーが検出されたフレームから定位開始
となりますので暗騒音(環境音)が少なくTHRESHが充分に低く設定できる環境では無音となります。
初期値として500ms(50frame)を設定していますが、音声の頭が切れない範囲で小さな値を
設定して頂くことに問題は無いかと思われます。
注）音声認識エンジンによっては発話区間の前に僅かな無音区間が必要な場合があります。

後方の無音区間は、SourceTrackerノードのPAUSE_LENGTHパラメータの影響です。
https://www.hark.jp/document/hark-document-ja/subsec-SourceTracker.html
PAUSE_LENGTHパラメータの説明に記載しているように、音源が失われてからも生存期間を
超えるまで定位を延長します。本機能は、発話中の句読点にあたる位置や息継ぎなどで
一時的に発生する無音区間(ショートポーズと言われる)で定位区間が分割されることを
防ぐという目的があります。
初期値として800[1/10frames]=800ms(80frames)を設定していますが、この値を小さく
設定する事で発話終了後の無音区間を減らすことが可能です。長文を読み上げた際にも、
意図しない位置で定位が分割されない範囲で減らして頂くことは問題無いと思われます。
遅延量は減りませんが、定位区間の終了が早くなる(出力するフレーム数が減る)事で
入力に対しての応答時間も改善されるものと思われます。

上記の2パラメータと無関係に無音区間が頻繁に定位するような状況でしたら、
SourceTrackerノードのTHRESHパラメータが低すぎる可能性が御座います。
定位区間が希望通りに得られれば外部VADのオーバヘッドも不要となる事が期待されます。

——————–

次に下記のご質問内容についてです。
> 実時間処理をしない方法はないのでしょうか。
マイク入力のようにリアルタイム入力ではなく音声ファイル(WAVファイル等)の入力のみを
想定して高速に処理出来るか否かというご質問でしたら可能です。
内部ではstream処理を行いますが、入力待ち時間無しで処理を行うため高速に処理されます。
AudioStreamFromWaveノードのUSE_WAITパラメータをfalseに設定します。
USE_WAITパラメータでtrueを設定した場合、AudioStreamFromWaveのファイル入力でも
AudioStreamFromMicの実時間動作をシミュレーションします。この機能を無効にします。

——————–

定位の精度について書かれていましたが、下記についてご確認ください。
LocalizeMUSICノードのWINDOWパラメータを変更する際、PERIODパラメータも同じ値に
変更されていますでしょうか。
WINDOWが処理する単位、PERIODが処理する間隔と考えた場合に分かりやすいのですが
PERIODが50の設定のままWINDOWだけ20に設定すると検出しない区間が発生するので、
定位精度が大幅に悪化する可能性があります。
特殊な用途を除いて基本的には WINDOW >= PERIOD となるようにご設定ください。
注）PERIODを下げるほど計算量が増えますので計算が実時間内に終わらなくなり、
かえって応答性能が悪くなる場合があります。下げすぎにはご注意ください。

——————–

最後に、SourceIntervalExtenderとLocalizeMUSICの両方で遅延が起きているか否か
については、バッファによる遅延以外(計算量の差による)の可能性も考えられますが
もう一つの可能性として下記が考えられます。
LocalizeMUSICノードのWINDOW_TYPEパラメータがFUTUREになっていないでしょうか。
https://www.hark.jp/document/hark-document-ja/subsec-LocalizeMUSIC.html

HARKはソースコードを全て公開しておりますので、お時間のある時にソースコードを
読んで頂くと具体的な挙動などを含め理解の助けになるかもしれません。

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

[橋口夏樹]

ご回答ありがとうございました。
何度も説明して頂き恐縮ですが、整理させて下さい。
ご承知の通り、マイクの入力から分離音が得られるまでの応答速度改善が第一目的です。

①（ADVANCE=160、window=50の場合）preroll_length=0でも50でも、frame0に対する定位情報は
同時刻（frame0が入力されてから約540ms後、つまり音声のframe50が入力されているころ）に出力され、その（frame0の）定位情報に基づき、

　－今のframe50から処理（分離等のノード処理）するのがpreroll_lemgth=0
　　（すでにframe0は過ぎてしまっているので、frame50から処理開始）
　－バッファから過去50frame分遡ったframe0から処理するのはpreroll_length=50

である。つまり、あるframeに対する定位情報を取得するのにかかる時間はpreroll_lengthの設定値により変わらないが、preroll_lengthの設定frame分streamは遅延（同じframe番号の音声入力と分離音出力を比較して）する。
preroll_lengthの設定を0にすれば、理論上streamの遅延はほとんど（1frame以下）ないはず（頭は切れるかもしれないが）。
という事でよろしいでしょうか。
（特に音声の終わりを早く検知したいので、頭は多少切れても良いと考えています。）

②pause_lengthについては承知しました。色々ためしたところ、pause_lengthを短くすると
細切れになってしまうため、pause_lengthは800～1200に落ち着いています。

③実時間処理の件は承知致しました。

④periodの調整に関しては承知しました。
ADVANCEやLENGTHの設定に関する注意事項、ポイント等はございますでしょうか。
（LENGTHは20～40msが良く、ADVANCEは後続フレームとフレーム全体の 1/3 – 1/2 重なる量シフトを指定すると記載されていましたが、デフォルトでは各512、160samplesということで、2/3が重なっている気がします。しかし例えばLENGTH=256にすると、うまく定位しませんでした）

⑤FUTUREになっていました。
今回のような用途の場合はPASTが良いのでしょうか。
上記①との関係も含めて教えて頂ければと思います。
FUTURE、PASTでも、あるframeの定位情報はどこのframeを使用するかということでしょうか？
分かりづらくて恐縮ですが、添付に整理しております。考え方はあっておりますでしょうか。
（preroll_lengthとの関係が理解できているか不安です）

Attachments:

1. .pdf

[Author]

Posts