Masayuki Takigahira

Forum Replies Created

Viewing 15 posts - 31 through 45 (of 57 total)
  • Author
    Posts
  • お問い合わせ、ありがとうございます。

    まず、お使いのサンプルファイルに同梱されている伝達関数は旧Kinect(v1)用のものと思われます。
    https://www.hark.jp/document/supported/
    より、Kinect v2用の伝達関数をダウンロードして頂き、差し替えて頂ければと思います。
    マイクのチャネル数が一致しているのでクラッシュはしませんがマイク配置は異なりますので
    今のままでは意図通りに動作していないと思われます。

    —————————————-

    下記は伝達関数が正しい場合、どのような動作となっているか記載しました。
    伝達関数をKinect v2用のファイルに置き換えてから読んで頂けますようお願い致します。

    添付して頂いた画像の音声ファイルがどのような定位結果で出力されたものか
    確認させて頂いても宜しいでしょうか。

    実行時にDisplayLocalizationノードによって定位結果がplotされていたかと思います。
    この時、「0.png」の定位結果と並行で「2.png」が定位していませんでしょうか。

    この場合、「0.png」の音声と「2.png」のノイズが分離された事になり正常です。
    SourceByDirectionノードなどを用いると音源情報をフィルタする事が可能ですので
    SaveWavPCMで音声を保存する際に自分の声の分離音だけを保存する事が可能です。

    GHDSSノードに入力する前にノイズの音源情報をフィルタしてしまった場合、
    ノイズを分離出来なくなり指向性を持たせるだけになってしまいます。
    GHDSSノードに入力するSOURCEはSourceIntervalExtenderから出力しているSource、
    SaveWavPCMに入力するSOURCEはSourceIntervalExtenderの出力を一度
    SourceByDirectionに入力し、SourceByDirectionでフィルタした後のSourceとします。

    「2.png」が「0.png」と無関係のタイミングで定位する場合。
    大量のノイズが定位してしまう場合、SourceTrackerノードのTHRESHを上げる事で
    不要なノイズを定位しないようにする事が可能です。

    もし、ご不明な点がございましたら再度お問い合わせください。
    その際、お使いのHARKバージョンとOS(バージョン込み)で情報を頂けると幸いです。

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

    in reply to: streamの遅延時間について part2 #849

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

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

    前方の無音区間は、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はソースコードを全て公開しておりますので、お時間のある時にソースコードを
    読んで頂くと具体的な挙動などを含め理解の助けになるかもしれません。

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

    パラメータタイプで object を選択した場合に入力可能な書式の例を挙げたthreadを立てましたのでもし宜しければご参照ください。

    threadの名前は下記になります。
    [Infomation] About the format when object is selected in parameter type

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

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

    添付されたネットワークファイルを確認させて頂きましたところ、
    ChannelSelectorノードのパラメータが原因と判明致しました。

    添付されたファイルでは <Vector <int> 1> となっていますが、
    Vector< の間に半角スペースを含まない
    <Vector<int> 1> が正しい書式となります。

    https://www.hark.jp/document/hark-document-ja/subsec-ChannelSelector.html
    の最後に例を記載しておりますので、ご参照ください。

    パラメータを object に設定した場合の書式に関する資料が
    整備されておらずご不便をお掛けしております。現在のところ
    下記などから書式に関する情報が得られますのでご参照ください。

    • HARK-Documentのノードリファレンス
    • HARK-Designer上で新規にノードを置いた際に予め入力されているデフォルト値の書式
    • HARK-Designerでパラメータ入力欄にカーソルを合わせた際に表示されるtips等の記述

    また、エラーメッセージ等が全く表示されない件につきましては
    大変ご迷惑をお掛けしました。
    今後のバージョンにて対応させて頂きたいと思います。

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

    in reply to: streamの遅延時間について #812

    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_usecint64_t ですので 64 bits (つまり、8 Bytes)で送られています。頂いたログではpythonのprint関数でASCIIキャラクタに変換されてしまっているものがありましたので、上記では元のHEXバイト列に戻しております。

    2019/04/08 追記2:
    おっしゃる通りWindows版でのみ問題が起きているようです。Windows版の旧バージョンに対する修正を提供する事が現状困難ですので、Ubuntu版で対応して頂けると助かります。

    in reply to: streamの遅延時間について #808

    ほぼ同じ構成のネットワークファイルを準備し、再現試験を行っておりますが現時点では再現出来ておりません。同じバージョンの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
    in reply to: streamの遅延時間について #805

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

    「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で発生しています。そのため、ソケットから送信するデータ構造が作れないためエラーとなっております。

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

    in reply to: streamの遅延時間について #797

    「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

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

    in reply to: streamの遅延時間について #793

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

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

    in reply to: streamの遅延時間について #790

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

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

    例えば、平滑化を行うノードでは複数フレームのデータを必要とします。
    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ノードを用いる事で
    常に指定した音源方向で分離したストリームを送信し続ける事が可能です。

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

    in reply to: 音源到来方向を制限する場合のGHDSS #750

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

    samples-hark-2_2_0.tar.gz のサンプルでは0度と-45度に2話者が立ち、同時発話を行っているデータとなります。

    ご希望されている動作は-45度方向の音声を抑圧し、0度方向の分離音声のみを得たいという事でしょうか。
    その場合、LocalizeMUSICの定位範囲は360度のまま変えずにGHDSSノードに入力し、SourceByDirectionノード等を経由して取り出したい結果(GHDSSの出力)の音源方向をフィルタする事になります。
    添付のpngファイルをご参照ください。

    或いは、定位する方向を-20度から20度の範囲に制限して分離対象となる音源方向を制限したいという事でしょうか。
    もし、分離対象から-45度方向を外すという事でしたらおっしゃる通りの結果になります。
    -45度方向の音源はGHDSSの分離対象から外れますので-20度から20度の範囲で定位した0度方向への指向性を持たせるのみの動作となります。つまり、-20度から20度の範囲に複数の音源があればそれぞれが分離されるはずです。

    特定範囲の方向以外をノイズとみなして破棄する場合は前者のように分離後に得たい方向のデータのみをフィルタして頂く使い方になるかと思います。つまり、SourceByDirectionでAzimuthを-20度から20度と指定して頂くとご希望の結果となると思われます。もしご希望される動作に対する私の認識が間違っていたら申し訳ございません。

    LocalizeMUSICが計算対象とする範囲の制限(MIN_DEG, MAX_DEG)は、例えば次のようなケースで使用されます。
    ロボットの冷却ファンが固定方向から常に出ている事が既知であり、その音が非常に大きいケースで音の検出方向から除外したいとします。
    LocalizeMUSICで冷却ファンが存在する方向を計算範囲から除外し、ConstantLocalizationで冷却ファンのノイズ方向を示す定位結果を出力します。次にLocalizeMUSICの結果とConstantLocalizationの結果をCombinedSourceノードで結合してGHDSSノードに入力します。最後にLocalizeMUSICの音源方向の結果のみを得る事で冷却ファンのノイズ以外の分離結果が得られます。

    ご不明な点、ご質問などございましたらお気軽にお問い合わせください。

    Attachments:
    in reply to: オフライン音源定位の出力グラフの維持 #745

    プロットされたウィンドウをそのまま図にしたいという用途でしたら、Windows/Ubuntuどちらの環境でもPrintScreenキーを押して頂くとスクリーンショットが取れますので代用して頂くことが可能です。Altキーと同時に押すことで対象のウィンドウのみのスクリーンショットとなります。
    WindowsではPrintScreenキーを押した後でペイントやPowerPoint等に画像としてペーストして保存する事が可能です。UbuntuではPrintScreenキーを押した後でpngファイルの保存画面がダイアログで表示されます。

    もし処理を行った全区間のデータを解析される用途でしたら、定位結果をファイルに保存した後に描画と図の保存は別途行われるのが確実かと思われます。SaveSourceLocationノードを使用して頂くとファイルに定位結果がXML形式で書き出されます。保存したXMLファイルには各frameで定位した音源のIDと座標情報、MUSICパワーが入っていますので、Python等を用いて画像ファイルに変換、保存する事が可能です。

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

    in reply to: マイクのチャンネル数について #719

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

    HARKでサポートしているデバイスは下記のURLに掲載しております。
    https://www.hark.jp/document/supported/

    購入後すぐに利用できるデバイスとしてはTAMAGO-03を推奨しております。
    研究用途向けという事もあり、PS-EyeやKinect等と比較すると高価になりますが
    マイク数も多く直線配置ではないため全方位(360度)の定位/分離に優れています。
    PS-EyeやKinectはゲーム機用に開発された事もあり、主にTVの正面側(180度)
    に対して定位する事が目的に設計されているためです。

    手元に無いため確認は出来ないのですが、お手持ちの Respeaker Mic Array v2.0
    については仕様書を見る限りですが正しく設定出来ればHARKでも使用出来るように見えます。
    UAC1.0に対応しているようですので仕様通りであればHARKでも動作するはずです。

    お使いの環境はWindowsでしょうか、それともVirtualMachine上のUbuntuでしょうか。
    まず、実際にHARKをお使いになる環境でaudacityというソフトウェアをインストールし
    録音が可能かご確認ください。
    WindowsではInstallerをダウンロードして実行する事で入れる事が可能です。
    Ubuntuでは sudo apt install audacity で入れる事が可能です。

    audacityで録音した際に6chで正常に録音ができていれば Respeaker のファームウェアは
    6ch用に書き換えられていると思われます。WiKiでもaudacityを使用して確認している様です。
    Ubuntuでご使用になる際は、 Respeaker が接続されたデバイス番号が間違っていないか
    ご確認の上でネットワークファイルを設定してください。
    USBデバイスは接続の度に(抜き差しの度に)番号が変わる事があります。
    内蔵に plughw:0,0 が設定されることが多いため plughw:1,0plughw:2,0
    になるかと思います。

    ネットワークファイルの設定ですが、
    AudioStreamFromMic ノードでは CHANNEL_COUNT を 6 (デバイスのチャネル数)に設定し、
    その直後には ChannelSelector というノードを接続します。MultiFFT等の前に接続してください。
    ChannelSelector ノードで SELECTOR を <Vector<int> 1 2 3 4> と設定する必要があります。
    理由は、マイクアレイの録音データではない不要な0chと5chを使用しないようにするためです。
    伝達関数を4chで作成している状態でLocalizeMUSICに6chの入力が来るとエラーします。
    そのため、必ずChannelSelectorで不要なchをフィルタしてください。

    手元に Respeaker が無いため確認は出来ませんが、仕様書の通りであれば上記の
    ChannelSelectorが必要になりますのでお試しください。

    また、動作確認として Respeaker で録音が出来ているかだけを確認するネットワークファイルを
    作成してみては如何でしょうか。
    AudioStreamFromMicの直後にSaveWavePCMを接続し、ファイル名の指定とbit数を合わせてください。
    6chのWAVファイルが出来ていればマイクとしては上手く動作しているのでネットワークファイルの
    設定の問題だけと思われます。

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

    in reply to: ubuntuでの起動 #697

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

    buffer overrun!!のメッセージですが、マイクアレイ(TAMAGO)の録音データを実時間で処理できずバッファが溢れた事を意味しています。つまり対処方法としては処理を軽くするか演算速度を向上させる必要があります。例として次のような対処が考えられます。

    1.定位処理に使用するLocalizeMUSICノードで行う計算は比較的重い処理ですので設定を出来るだけ軽くする(精度とはトレードオフとなります)という解決方法が考えられます。LocalizeMUSICの設定例としては次の通りです。

    アルゴリズムをGSVDに変更する。
    デメリット:ノイズ相関行列入力が無い場合の影響はSEVD/GEVD/GSVDいずれを使用しても影響はありませんので最も処理が軽いGSVDを選択してください。ノイズ相関行列入力がある場合はGEVDに比べるとGSVDの方が精度は若干悪くなります。

    PERIOD(検出周期)を増やす。
    デメリット:定位の追従が遅くなります。WINDOWより大きくすると短い定位を取りこぼす可能性があります。

    2.公式としてはFAQ(*1)に記載していますようにIntel互換プロセッサ環境をサポート対象としており、パッケージもそのような環境向けに提供しております。
    (*1) https://wp.hark.jp/faq/#What_are_the_supported_architectures_by_HARK

    一方でラズパイは組み込み向けARMプロセッサを搭載していますので、一般的なPCよりも性能が低いためユーザご自身の手でコンパイラオプションを指定し、各ARMプロセッサに対して明示的に最適化して頂く必要がございます。主要なARM系組み込みボードのCFLAGS/CXXFLAGSの設定例は以下の通りです。OSのビルド設定により適合しない事がありますのでご了承ください。例:-mfloat-abiでhardが使用できない場合、softやsoftfpなどに設定する必要があります。

    Raspberry Pi 1 (Broadcom BCM2835) :
    -mcpu=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp
    または
    -march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp

    Raspberry Pi 2 (Broadcom BCM2836) :
    -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4
    または
    -march=armv7-a -mtune=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4

    Raspberry Pi 3 (Broadcom BCM2837) :
    -mcpu=cortex-a53 -mfloat-abi=hard -mfpu=neon-fp-armv8 -mneon-for-64bits
    または
    -march=armv8-a+crc -mtune=cortex-a53 -mfloat-abi=hard -mfpu=neon-fp-armv8 -mneon-for-64bits
    *)OSが32bit環境の場合、最後のオプションは外してください

    BeagleBone Black (TI Sitara AM3358/9) : -mcpu=cortex-a8 -mfloat-abi=hard -mfpu=neon
    Altera Cyclone V5 (5CSEMA4U23C6N A9) : -mcpu=cortex-a9 -mfloat-abi=hard -mfpu=neon

    また、高速化の為に下記のオプションが併用されることがあります。
    -fomit-frame-pointer (実行結果に影響はありませんが、有効にするとデバッグがほぼ不可能になります)
    -ftree-vectorize

    以下のオプションは高速化に寄与しますが、規格通りの結果が保証されなくなるため安全ではありません。使用しない事をお勧めします。
    -funsafe-math-optimizations
    -ffast-math
    -fno-protect-parens
    -fstack-arrays

    3.ラズパイ等が使用するストレージはSDカードであるため、書き出し速度が遅くボトルネックとなる事があります。ファイルへの書き出し(分離音や定位結果)をされている場合は、tmpfs等のRAMディスク領域に書き出し先を変えると改善する可能性があります。

    4.TMAGOを接続しているUSBポートにHub等を接続している場合、Hubを経由せず直接接続すると改善する場合があります。TAMAGOへの電力供給の問題である場合は逆にSelf-poweredのHubを経由する事で改善する事があります。また、複数のUSBポートがある場合は他のUSBポートに挿すと改善する事があります。

    5.ラズパイの場合は手元に無いので不明ですが、ARMプロセッサの場合でもIntelのSpeedStepのように省電力機能でプロセッサに制限が掛かっている場合があります。低いクロックからの復帰が遅いプロセッサの場合、クロックを固定する事で改善する事があります。

    上記の対策を一通り試みた上で改善できない場合には残念ながら性能不足の可能性が御座います。

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

    in reply to: SaveFeaturesの保存ファイルについて #678

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

    SaveFeaturesノードの出力するフォーマットはリトルエンディアンのfloat型となっており、
    特徴量の次元数 x フレーム数 でファイルに書き出されます。
    またPythonの場合、struct.unpackでバイナリからPython内部型へ変換する事が可能です。

    SaveHTKFeatureと異なりヘッダ等はありませんので読み込んだデータは全てfloatとして
    unpack可能です。

    参考までに

    
    import sys
    import struct
    
    dim = 40
    frames = 1000
    float_size = 4
    
    frame_size = float_size * dim
    
    infile = open(sys.argv[1], 'rb')
    data = infile.read()
    infile.close()
    
    offset = 0
    for x in range(0, frames, 1):
        frame_data = data[offset:offset+frame_size]
        offset += frame_size
        print(*struct.unpack("<{}".format("f"*dim), frame_data))
    

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

Viewing 15 posts - 31 through 45 (of 57 total)