Masayuki Takigahira

Forum Replies Created

Viewing 15 posts - 31 through 45 (of 55 total)
  • Author
    Posts
  • パラメータタイプで 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))
    

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

    in reply to: 雑音情報ファイルの生成について #666

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

    NOISEi.datが生成されない件ですが、HARK2.1以降の仕様動作であり正常です。
    正確には、ファイルフォーマットがzip形式に変更されており実部と虚部の両方が1つのzipファイルに格納されています。ファイル名の設定をNOISEr.datからNOISE.zip等に変更してご利用ください。

    クックブックでnode_Constant_1が2つ存在していた件、混乱させてしまい申し訳ございません。
    Iteratorシート側に200、Mainシート側に雑音の入力ファイル名であっています。

    クックブックに古いバージョンの記述が残っている件、ご迷惑をおかけしております。
    現在、少しづつではありますが改訂作業を進めている状況です。
    HARK-DocumentのノードリファレンスやFAQの更新を優先しており、それぞれには記載が御座います。
    関連している箇所について挙げさせて頂きます。

    HARK-Documentのノードリファレンスより、CMSaveの項目
    https://www.hark.jp/document/hark-document-ja/subsec-CMSave.html

    FAQより、「NOISEr.datは生成されるが、NOISEi.datが生成されない」の項目
    https://wp.hark.jp/faq/#While_trying_to_create_noise_file_for_suppressing_noise_the_real_part_NOISErdat_is_being_created_but_the_imaginary_part_NOISEidat_is_never_created_Why_is_this_so

    FAQについては英語のみの提供となっており、大変恐縮ではございますがGoogle翻訳などをご活用ください。

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

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

    HarkDataStreamSenderノードはsocket通信のTCP/IPプロトコルで バイナリデータ を送信します。バイナリデータですので、toStringやUTF-8変換などを行っては いけません のでご注意ください。
    データ構造につきましては下記URL(HARK-Documentのノードリファレンス、HarkDataStreamSenderの項)の「データ送信の詳細」以降に記載しております。
    https://www.hark.jp/document/hark-document-ja/subsec-HarkDataStreamSender.html

    記載している情報ですが、C/C++の型情報に基づいておりますのでnode.js上でのデータの扱い方を簡単に書かせて頂きます。node.jsでは特定のモジュールを使用しなければ64bit整数を扱えないようですが、下記のような構造ですので時間情報が必要な場合でも、精度の高い時間情報が不要でしたらフレーム数(sampling=16kHz、advance=160の場合1フレームあたり10ms)から算出する事が可能です。

    
    buf = new Buffer([0x04, 0x00, 0x00, 0x00, 0xa0, 0x00, 0x00, 0x00 ... 受信データ ...]);
    
    // ---
    hdh_type    = buf.readInt32LE(0);  // HD_Header (type)    : SRC_INFOを意味する 0x00000004
    hdh_advance = buf.readInt32LE(4);  // HD_Header (advance) : ADVANCE=160を意味する 0x000000a0
    hdh_sec     = buf.readInt32LE(8);
    hdh_sec    *= (2 ** 32); // 恐らくモジュールを追加しなければオーバーフローします
    hdh_sec    += buf.readInt32LE(12); // HD_Header (tv_sec)  : 1960/01/01 00:00:00 からの秒数
    hdh_usec    = buf.readInt32LE(16);
    hdh_usec   *= (2 ** 32); // 恐らくモジュールを追加しなければオーバーフローします
    hdh_usec   += buf.readInt32LE(20); // HD_Header (tv_usec) : 同上からのマイクロ秒(秒数未満)
    // ---
    srcs        = buf.readInt32LE(24); // Sources             : 音源数(下記HDH_SrcInfoの個数)
    // ---
    for(var i = 0; i < srcs; i++){
    
    src_id[i]   = buf.readInt32LE(28+i*20+0);  // HDH_SrcInfo (src_id) : 音源iのid
    src_x[i]    = buf.readFloatLE(28+i*20+4);  // HDH_SrcInfo (x[0])   : 音源iのx座標
    src_y[i]    = buf.readFloatLE(28+i*20+8);  // HDH_SrcInfo (x[1])   : 音源iのy座標
    src_z[i]    = buf.readFloatLE(28+i*20+12); // HDH_SrcInfo (x[2])   : 音源iのz座標
    src_pow[i]  = buf.readFloatLE(28+i*20+16); // HDH_SrcInfo (power)  : 音源iのMUSIC power
    
    }
    // ---
    

    毎フレーム上記のようなデータが届きます。また、音源数 i は定位した音源が無ければ 0 となる事もあります。その場合はループ内のデータ構造(HDH_SrcInfo)部分は受信しません。

    デカルト座標から極座標に変換される場合は、下記URLの座標系の説明をご参照ください。
    https://www.hark.jp/document/hark-document-ja/sect0030.html

    以上、ご参考になれば幸いです。

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