RemAudの調整
こちらの続きです。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に変えるとまた設定値が変わってくるのではないかと思われます。
--
しばらくこの設定で運用してみます。不具合があればまたやり直しでしょうねぇ～。