とりあえず作ってみたブログ

　こちらの続きです。DF3CB氏作のRemAudの調整方法を試してみました。調整を方法を解説した先人の記録があればよいのですが、残念ながら見つけられませんでした。当方で試した結果から、以下のようになっていると想像します。これを、備忘録としてまとめておきます。(最新版のVer2.1を使用)

〇使用環境について

・remaudの伝送設定は16bit、サンプリング周波数22kHzのモノラル。
・運用環境はフレッツ網内(Ipv6)の折り返し通信によるVPN。
　回線遅延は片道５～７mSと思われます(大阪⇔兵庫県西部の間）

　おそらく、これが低遅延かつ落ちにくいネットワークを最安で構築する方法だと思います。その代わりにNTTの東西を跨ぐことが普通にはできません。(別料金を払えばできるようですが・・）

〇レイテンシー(遅延量)の見積もり

　多分、この考え方であっているはずです。

遅延量＝送信パケット長＋回線遅延＋(受信パケット長×バッファー数)＋PC処理(ADとDA)

　送信パケット長はサーバー側のこの画面の黄色の丸印。ご本家だとここです。



　受信側。クライアント側の設定はこの画面です。ご本家ではこちらです。

　

　クライアント側が遅延量のカッコの部分です。赤が受信パケット長。青がリミットバッファー数。遅延量は、受信パケット長と使用バッファー数の掛け算になっているとみられます。クライアント側の右隅に出る数字（赤丸）が再生しているバッファー位置、すなわち青丸で指定した量の中で実際に使われている部分を示していると思います。

〇送信パケットサイズの調整

　まず送信側から調整。データサイズを小さくすると、遅延は短くできますが、ショートパケットを短い間隔で投げ続けることになります。となれば、PCのネットワークカード、ルーターの処理に負荷がかかることになります。（ルーター、ショートパケットを連発するとスループットが落ちます）なので、程よきデータサイズを探ることになります。（送信パケット長が10mSなら１秒間に100回送信、40mSなら25回に減ります。)

　故意に、受信バッファーを最小にした状態を作ります。（クライアント側の青丸を「１」にする。赤丸は「１０」。）
送信側の送信パケット長(黄丸)を10から順番に増やして変化を見ます。最初の10mS設定では、おそらく音がブツブツにぶっ飛んでしまうはずです。音がブツブツに切れる状態から抜けるまで、増やします。増やしすぎると、遅延が増えるので、ブツ切れにならないところでストップ。

　当方の環境だと。10～20mSでは、ブツブツでNG。30mSだと、数十秒に１回で音が途切れる。40mSで収まりました。ということで、ここは40mSで固定。

〇受信側の調整

　受信の調整、最終的には、赤丸の受信バッファ長10mS、青丸のバッファーオーバーランのリミットは「0」(自動)に落ち着きました。

　当初は、送受のパケットサイズを一致させて、バッファーのリミット(青)を積み上げていくという方法でした。これでも、安定ポイントは見つけられます。ただ、時間とともにバッファー量が増える傾向があります。バッファーの状態は、上の画のクライアント側の赤丸部分です。こちらの環境では、送受のデータ長を40mSとしたとき、接続時は使用バッファー数が２程度で収まり、実測した遅延は110mSぐらい。ところが時間とともに増加し、バッファー数が６になったころには、遅延は260mSまで増加しました。
　送信パケット長を固定し、受信パケットサイズを送信より大きくした場合も、一致した時と同じ傾向です。遅延が時間とともに増えました。
　送信パケット長より受信パケット長を短くしてみたところ、比較的低遅延で動きました。表題のキャプチャーがその状態の遅延量実測画面です。Ｌ側にAMラジオの受信音、Ｒ側がリモートシャックで受信した音声です。(この実測方法の子細はこちらで)

　バッファー量の数字ですが、青丸のリミット設定以内であれば緑表示。リミットを超えると赤表示に変わります。赤表示だと、音飛びが起こるという意味ではなく、設定よりバッファーの使用量が多い、という警告表示に過ぎないようです。またリミットを超えると、バッファーが生成されなくなるというわけでもないようです。この数字が大きいほど、遅延も多くなっていきます。受信側は、この数字が緑の範囲になるように落とし込めると良好な状態が確保できているという事になるかと思います。

〇最後に勝手な想像

　ここからは想像(妄想?)です。
　データのやり取りがTCPのため、必ずackが戻りますし、ダメなら再送。となると、送信パケットはそれなりの大きさにして、データ送信回数を減らすほうがトラフィック量が減り無難な感じがします。
　受信パケットサイズの件。当初は一致、あるいは送信より長くして、再送に備える・・という発想でした。この設定では時間とともに遅延が増える方向へ傾くようです。受信バッファーが埋まらないとサウンドカードへデータが送られないのでしょう。また受信バッファーはどんどん生成されるようです。リミットを設定してもリミット以上に作成させるようです。
　結局、受信バッファーを短めに設定して、届いたデータは逐次サウンドカード側へ流してしまうほうが、時間がたっても遅延が増えにくい感じです。
　受信側のPCの能力にも遅延量は支配されるはずです。今の受信側はceleron4100のノートPCなので、処理能力の高いPCに変えるとまた設定値が変わってくるのではないかと思われます。

--

　しばらくこの設定で運用してみます。不具合があればまたやり直しでしょうねぇ～。

　リモートシャック関連です。この前のALL　JAコンテスト中に気が付いた不具合修正をメモしておきます。

　

　CPUパワーの消費状況を比較してみました。左が修正前、右が修正後。起動しているアプリケーションの割には、CPUパワーが喰われています。タスクマネジャーで変なプロセスがいないか?見て気が付きました。

　・Windows Image Acquisition（WIA）が高CPU状態になっている。

　今の用途には、画像取り込みなんて不要、タスクマネージャーで強制停止したところ、あっさりCPU食いつぶし状態が改善したのでした。ついでに、サービスの起動を自動(遅延)としておき、立ち上がりにくいようにしておきます。

　今のホストPCに交換してから、CPUパワーの割にイマイチな反応だなぁと思っていましたが、どうやらずっとこのWIAサービスが無意味に働いていたのが原因っぽい感じです。この状態でしばらく使ってみて様子を見ます。これでもダメなら、WIAサービスは手動にして起動しないようにすることになるかと思います。

　コンテスト後になりますが、音声伝送周りを修正しました。



　RemAudのbufferサイズを変えました。もともと20mSだったのを40mSへ増やしています。クライアントソフトの右下(赤丸)の数字がバッファーの消費状態を示すようです。数字が大きくなり、緑から赤に文字が変わると状態が悪いと見てよいようです。赤文字の状態で悪化するとデータ欠落による音飛びやノイズが出ることもあります。
　こちらの環境では20mS→40mSと増やすことで、ほぼ常時緑文字だと思います。こちらもしばらく運用して様子を見るしかありません。

　バッファーを増やせば安定性は向上しますが、レイテンシー(遅延)が相応に増えます。過剰なバッファー追加は、リニアPCMの非圧縮によるエンコード・デコードのレイテンシー短縮というメリットを捨てることになりますので、妥協できるポイントを探すしかないと思われます。(音声圧縮の場合、エンコード・デコードで遅延が必ず発生し、リニアPCMより大きくなります。なお、遅延量は圧縮アルゴリズムやデータレートにより大きく変動します)

[2022.4.28 21:12ごろ追加]
クライアントのバッファーの数字の意味は、再生中のバッファー位置を表すようです。赤字になると、バッファー量が多すぎるという警告で、パケットロス等の品質を表すものではないようです。故意にバッファーを詰めると、緑字でも音がブツブツに切れました。詳しくはもう少しあれこれ試してから・・
該当部分の説明はこちらのリンクを！

　

　夜間勤務多め、昼間の隙間で製作しました。しかも２台作ってしまいました。小さいほうこちらで使うつもり、もう一台の大きいほうはリモートシャック用に持ち帰ろうかと思ったり。(大きいほうは、zlogとMMTTY、兼用版です)

　この回路図と同じもので最初に作ったのは20年以上前です。実家では、基板むき出しのまま、小さいポリ袋に収容して、とりあえず絶縁確保、そんなええ加減な状態で20年ほど使っていたりします(笑)。そろそろバラックを卒業せねば。。。ということで作り直したのでした。

　この手の、CWキーイングIF、やり方はいろいろあるはず。個人的に実績のある回路にしてしまいました。世間にあるものを参照すると、BE間に入っている47kΩは無くてもいいように思われます。

＃どこかのデッドコピーだけど、どこで見たものか失念しました(^^;;

無線関係の事務作業２件の備忘録です。

〇その１
　移動する局の再免許申請。電子申請でポチリました。

〇その２
　1kW局の電波利用料を納付。

　以上、備忘録でした。

　リモートシャック関連。VSPEを使ってシリアルポートのネット越し操作を試してみました。具体的な手順はこちらに詳しく書いてあります。先人の知恵をありがたく利用させていただきました。

〇サーバ側(HostPC)
・新規作成でTcpServerを選ぶ、事前に用意した仮想ポートを割り当て。
・Windowsからのファイアーウォールの警告が出るので、VSPEも例外追加

〇クライアント側
・新規作成でコネクタを選択して、仮想ポートを作る
・作った仮想ポートへTcpClientを割り当て。server側のIPアドレスとポート番号を合わせる。

　という操作で、comポートのネット越しが出来ました。早速、実家にあるTS-590SGを実際に接続されているホストPCからと、自宅のリモート側のPCから、同時にコントロールソフトを立ち上げてみた、というのが表題のキャプチャです。

　あとは、キーイングをうまく処理できれば、ホストPCでzlogを立ち上げてリモートデスクトップで触るということをしないでも、手元のPCでzlogを立ち上げリモート先のリグをコントロールできますねぇ。

　週末実家へ行きましたので、リモートシャックのホストPCを入れ替えてきました。処理能力はVer2の倍ぐらいあるはずです。

構成はこんな感じ
・CPU　Core i5-10400
・Mem　8GB
・SSD　500GB(M2)
・OS　Win10PRO(64bit)
・サウンド　サウンドブラスタ　Audigy FX
・シリアルポート　５ポート　（４ポート追加)

　サウンドのオンボードはどうなんだろう?ってことで、エントリーモデルだけど内蔵カードを追加してみました。
　PC起動は、外部から接点渡しでも可能ですが、今のところWOLだけも問題なさそうなので接続しませんでした。PCへ外部制御機能を追加したけど、なくても大丈夫かも(^^;;;
　リグの電源制御は復活しました。これで、スイッチング電源入れっぱなしで放置しなくて済みます。
　シリアルポートは4ポート追加して、5ポート化します。VSPEは、OSの64BIT化に伴い、FREE版を卒業してライセンスを購入しました(^^;;

　という事を反映した、Ver3のリモート構成図が以下です。



　この状態でしばらく試してみます。

　現時点のリモートシャックの構成図です。全体を描いたものが無かったので作ってみました。フォーマットはこちらの方のアイディアを参考にいたしました。多分、これでどんなソフトをどう使っているのか？ほぼ網羅しているはずです。

　それから、リモートシャック関連でカテゴリを追加です。過去の分も、追いつく範囲でカテゴリ変更しましょう。

[2022.3.15　夜追記]

　リモートシャック構築当初の構成図も作ったので貼り付けます。



　当初、操作側のPCは１台でした。zlogとリグコントロールソフトと音声伝送のVoipツール。いろいろなものが同居すると操作性が悪いです。何度かテスト運用を行った結果、リグ操作とログ操作、PCを分離するほうが良い、という結論に至ったのでした。Core2DUOでは、動くことは動きますが、ふとした瞬間に動作が重くなることがあり、処理能力不足でもありました。

　また、リグの受信音の伝送がkenwood純正のソフトでした。こちらは低ビットレートで、ネット環境が悪くても音声は通りますが、パイルになったときや弱い信号は了解度が劣ります。あと、圧縮遅延もそこそこあるのが気になりました。ってことで、あとから非圧縮のリニアPCM伝送へ切替えました。
　フレッツ網内折り返しのVPNを構築したことから、少々帯域を喰ってもデータ欠落が起こりにくいのでリニアPCM伝送ができます。業務用のルータでIPv6を使うというのが構築のポイントです。(ヤフオクで調達)

　最初のhostPCはOSがWin7PROでした。windows純正のリモートデスクトップが使えるのは便利でした。今のHost2は、CPUがXEONのため処理能力に問題はないと思いますが、HOME版のため純正のリモートデスクトップが使えないのは残念です。次のホストマシンはWin10PROで用意しました。次に実家へ行くとに設置できたらいいなぁー。

　こちらのPC組み立ての続きです。リモートシャック用に実家へ置き去りにするにあたり、WOL以外に外からの制御で電源ON、電源ONのアンサーを戻す基板を作成して追加しました。



　基板はこんな感じに仕上げてます。D-SUBはシリアルコネクタと間違えないよう、電源ピンもあるため短絡防止で、メス座にしておきます。本当は15pinなど全然違うものにしたほうがいいと思います。回路図は以下です。



　電源ONとアンサーはフォトカプラを使って、外部とは縁切りしています。他には、+5Vと+12Vの電源を外へひき出しておきます。本当はFUSE的なものを挟んでおいたほうが安全ですが、電源制御箱のためだけに引き出しているので保護回路は割愛です。

ピン配置はこんな感じ。

D-SUB
９ピン(メス座)
1.+5V電源
2.GND
4.+12V電源
5.GND
6.オン表示(+)
7.オン表示(-)
8.電源オン制御(+)
9.電源オン制御(-)

　電源オン制御は電源スイッチにパラ掛けしているだけです。フォトカプラなので、極性を合わせないと動きません。まぁ、２択なので、カットアンドエラーで確認しても十分かと。
　ON状態表示、PCの電源ユニットの起動で見ています。簡易なので、これで十分かと思われます。

　表題の写真が、PCへ基板を実装した様子です。軽く動作試験だけして蓋を閉じました。次、実家へ行くときに設置します。

〇備忘録
・Win8以降、WOLの子細が変わっている模様。こちらを参照。
・拡張４シリアルカード追加。余っていた、AREAのSD-PE9901CV-4S(E4S)。
　ドライバはこちらから。

　

　リモートシャックからの音声伝送、どれぐらいのディレーとなるのか？簡単に比較してみました。

〇測り方
AMラジオの受信音をＬチャンネル、リモートシャックの受信音声をＲチャンネル、として同時に録音して波形を比較。

　単純ですが、これが一番簡単です。また、この比較にはNHKが一番最適でしょう。その理由は、電波が民放より強いこと、トークに隙間が多いから波形比較を行いやすい、というあたりでしょうか。さて測定結果です。

・RemAud 233.3mS
・ARVP10H　432mS

　予測通り、非圧縮伝送のRemaudのほうがディレーは短めです。比較ソースはNHKの第一です。

　NHKの送信点から自宅まで20km前後、リモートシャックとNHKの送信所までは110km前後と場所が全然違います。ざっくり、1uSあたり電波は300m進むので、経路差が90kmだと300uSの到達時間差。0.3mSなので、大勢には影響のないところかと思います。

　表題の写真は、セッティング風景。録音は別のPCで・・。右のスクリーンショットは、RemAudでのディレー確認をしたところです。

　広島県からの届き物。RTC-59です。この基板を使えば、ローテーターをPCからコントロールできます。リモートシャック、タワーを伸ばしてフルに使えるようにするにはもう少し作業が残っていますが…最近は半導体不足で、欲しいときに手に入らないってことが良くある話なので、基板があるうちに確保しておきます。