緑のボタンを押せ! Press the green button

　Linux上で、キャプチャするための簡易ソフトの話。

いままで。ずっとvmplayer上のubuntu server 7で動かしていましたが、新しいドライバの不調の原因を突き止めようと、ubuntu desktop 8に移行というか変更して調査していました。不調の原因はつまなるミスで、動くようになりましたが、並行してディスクにアクセスしたりすると、キャプチャが止まってしまう、という新たな問題が出てきました。

というのが、ここまでの経緯です。キャプチャ用の簡易ソフトはやってることは、つまるとこファイル間のデータコピーなのですが、ソースとなるHD PVRからはリアルタイムでデータを引き抜く必要があり、一方ディスティネーション側のHDDは本質的にはリアルタイム性はないわけです。で、ソースから一定量データをバッファ読む、ディスティネーションにそれを書く、をシーケンシャルにやっていると瞬間的に間に合わなくなることがある、というのが考察です。

このような場合の常套手段としては、バッファを複数もって読み出しと書き込みを並行してやるわけですが、そのためにはスレッド・プログラミングとかをするのですが、なにせ私がc言語を真面目に使っていたのは、MS-DOSの時代なので、概念はわかっているつもりでもちょっとチャレンジングでした。ハイ。

プログラムは今のところ問題がないレベルに仕上がったのですが、ものはついでなので、topとか動かしながら、システムに負荷をかけたりしてすこし様子をみてみました。以下、雑多な考察。

簡易キャプチャソフトの負荷 は、topで見ている限りは1～2％なので、一応合格でしょう。vmplayer上のlinuxでも問題ないでしょう。

意外にsambaが重い 。linuxのシステムは、C2D7200,メモリ2GB,HDDはＨＧＳＴの７２５０５０ＶＬＡ360とファイルサーバーには豪華仕様です。Windows機からsambaで公開しているボリュームにビデオのファイルのような巨大(数GB)なファイルを読み書きすると、40kＢ/sec位は出るのですが、このときサーバー機上のsambaデーモンはCPUを30%くらい喰ってます。Atomベースのマザーボードにそのうち切り替えようと思っていたのですがちょっと考え物かもしれません。LANを100Ｍに設定するとか、Jumboフレームを導入するとかすれば状況は変わるでしょうが、我が家はまだ100Ｍの機器もあるので、悩ましいです。

一番キツクなるタイミング は、数GBとか巨大なファイルをまとめて消したりするときのようです(ファイルシステムはext3)。HDDの音を聞いていても、「カッ、カッ、カッ、」と音がします。

バッファサイズの適正量とその運用 。いま一本のバッファを4096Byteにし、1024個のバッファを用意しています。プログラムにちょっと細工をしてどれくらいのバッファが埋まっているか調べるようにしました。ピークでは450くらいまでいくのでもう少しバッファの個数を増やしたほうがよさそうです。
一本のバッファの大きさは「何の考え」もなく4096にして、スタティック変数にしてあります。ほぼ100％ページバウンダリをまたぐので、I/Oはスキャッタ・ギャザーDMAだとしてもあまりよろしくないかも・・・
あと今の実装ではソースデバイスからのデータの読み出しスレッドは 全速力 で読んでますが、一回のread()関数の読み出しでバッファがすべて埋まらない可能性があります。usleepとかで少し「待ち」をいれた方がいいかもしれません。

で、「PAC3」は本当に当たるのか?