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

　リモートシャック関連の備忘録です。久々にWSJT-Xの設定をしたらはまってしまいました。しばらく、リグコントロールができない、HAMLIBエラーに悩まされていました。



　この状態で、やっとOK。なお、COM10はVSPEによる仮想ポート。本来のリグはCOM2ですが、遠隔のためリグコントロールアプリとWSJT-Xを同時に使うためにVSPEで仮想COMポートを作り共用しています。

　すごくはまってしまいましたが、初心に帰ってこちらを見て間違いに気づいた次第です。スプリットの設定、それから、制御信号の強制設定もいるみたいです。
　とりあえず、これで受信はできるようになりました。送信はまた改めて手を付けます。ってことで、送信もVOXではなくCATに変えないといけないでしょうね。

＃リグコンはRS-232C、音声は背面ACCからとっています。
＃送信はまだ試していません。後日やりましょう。

　世間は10連休なところもあるそうですが、我が家は無縁(笑)。ちょっとだけ実家へ顔を出した際、両親と暇つぶしも兼ねて行ってみたのが、児島ジーンズストリート。
　実家からだと片道90kmぐらい、高速道路で行けば１時間ちょっとなので、日帰りでちょこっとならええかも。ただ、下調べしたほうがよさそう。当然のごとく店が多く、どこへ行けばいいのやら…(おいおい)。とりあえず、妻のジーンズが欲しい、というオーダーはクリアーできたのでええことにします。
　ちょうどお昼時だったので、下津井港あたりまで足を延ばしましたが、連休中、どこも一杯で昼食難民になってしまいました。
　次はちゃんとリサーチして出直すことにします。表題の写真は、立ち寄った鷲羽山からの眺めです。昨日はいい天気でした。

　RemAudの調整の件、続きです。と言っても、やり直した・・ではなくて、クライアント側のCPUパワーの違いによる状況を比較しておきます。ともに、ノートPCでOSはWin10PRO。ネットはWIFIで接続、同じ室内なので同じアクセスポイントへつながります。RemAudは、16bit、fs=11kHz、mono、送信パケット長は40mS、受信バッファー10mSという設定です。SSB/CWにおいては、fs=22kHzは過剰でしょう。AMラジオを聴きたいから、fs=22kHzにしていたり(笑)

〇Core i5-i5-1135G7の場合



　リグコンのソフトと同居しても、リモートデスクトップが同居しても大丈夫。時間とともに遅延増加。。ってこともなさそう。さすが、バックグランドで受信音を再生しながらWEB閲覧すると、遅延が増えることも・・。これでも耐えられるようにするには、もうちょっと高価なPCを買わないといけません(笑)

〇Celeron N4100の場合

　

　２つ貼り付けます。左側がリグコンと同居した場合です。右側がリグコンソフトの通信を切った状態。これだでかなり変わります。kenwoodのリグコンソフトは常時100kBPSぐらいの帯域を使うようです。それでも影響されます。明らかにバッファー使用量が異なります。遅延もその分全然違います。この状態でweb閲覧したら、そのうちに音が飛ぶんじゃないかと思われます。

　やはり、処理能力はCPUパワーに依存します。CeleronN4100のノートpcで音声を取っていましたが、もう少しCPUパワーのあるPCで伝送したほうが良いかもしれません。

　世間には10連休って会社もあるらしいが、こちらは「そんなの関係ねぇー」、ってことで、今日も徹夜明け。それにしても今朝はめちゃ冷えました。５月か?って思ったぐらい。京橋で久しぶりに廻っている寿司屋に行ってみました。毎度ながらBEERの類は自粛です。

　こちらの続きです。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に変えるとまた設定値が変わってくるのではないかと思われます。

--

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