NuDCLその14

サンプルコードのNuDCLを使ってFireWire経由でデータを受け取る部分は前回までで見終わった。だらだらとしたコードで非常に読みにくかった。最後まで見終わると最初の方を忘れてしまう。これは僕の忘却力のせいもあるけど、このベタ書きのコードのせいもある。一通り終わったので総括する。

3.12  まとめ

何をやっているかはだいたいわかった。しかしいくつかわからないことも残っている。

3.12.1  cycleとsegmentの関係

UniversalReceiverTest.cppではナマのパケットを処理するのではなくAV Protocolを念頭に置いているらしい。コンストラクタは具体的には

• cycleBufferSize=2048
• cyclesPerSegment=2000
• numSegments=3

という値で初期化されている。2重ループを一周するのに6MBという大きなデータを受け取ることになる。もしフォーマットがMPEG-2なら何フレームも収まってしまうし、IIDCならフレームをまるごとバッファリングできるぐらいの大きさになってしまう。そんな使い方していいのか？

ぼくはもっとDCLのバッファは小さくてそこからコピーするときにフレームを組み立てるべきなんだろうと考えた。なぜならDCLはひょっとするとkernel空間のメモリも消費するかもしれず（少なくともkernelオブジェクトとしてIODCLTranslate???などというクラスはある。DCLに直接対応しているかどうかはわからないけど）、小さいにこしたことはないだろうと思ったから。そのへんは実装をみなければわからない。

でもこれでいいなら、IIDCでも1フレーム分バッファを持っていて、フレームが完成したかどうかはDCLで判断すればいいということになる。これはまえやった複雑な実装（メインスレッドの方でパケットのヘッダをみてフレームの先頭を探すなど）をやらずにすむ。そりゃこっちの方が楽。

3.12.2  over runの処理

over runしたときのコールバックでは、転送を一旦止めて再開すると言う方法をとっている。これはバッファをカラにして先頭からやり直すことが自動的にできるので簡単なんだけど、たぶんオーバーヘッドが大きい。おそらくMPEG-2などのデータの場合、その先頭を知るのが面倒だと言うのがあるのだろう。

IIDCの場合には、フレームの構造が単純なので転送は継続してフレームの先頭のパケットを探した方が効率的になる、という気がする。

3.12.3  バッファのページアライン

古いDCLではデータを受けとるバッファはページをまたいではいけない、となっていた。techNoteにはパケットごとのバッファがページにきっかりでない場合、余白を作ってかならずページをまたがないようにするための計算が示してあった。

しかしこのサンプルコードではNuDCLでも古いDCLでもアラインメントをまったく気にしていない。これはどういうことだろう。たまたまページにぴったり収まるようなパケットサイズを前提にしているのかもしれないけど、そのサイズはクライアントオブジェクトから渡されてくる引数になっていて、特に何のコメントもない。

もともと絶対ダメというわけではなかったんだろうとは思うんだけど、これだけあっさり無視されるのはちょっと理解できない。