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

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