すぐ太るのである。

といっても私は肥満ではない。体重でいえば標準の範疇に入る。

しかし、腹の周りにはしっかりニクがついている。加齢とともに垂れ気味になってきていて、垂れ気味具合が増加傾向にある。

腹囲はメタボぎりぎりセーフである。

しかし、このニクはとれないのである。
Wiiスポーツをやっても、昼ごはんをバナナ1本、おにぎり2個にしても取れない。

それどころか、長期休暇などでどこにも出かけずボーっとしているとすぐ2、3キロ太る。

加齢とともに太る体質になってきている気がする。

去年の健診では脂肪肝だと言われた。今年は脂肪肝はなんとか免れた。しかしニクは取れていない。

このニクを取るには相当激しいトレーニングをするか、絶食するかしかないのであろうが、体力も気力も加齢とともに落ちてきているのでそういう行動を起こすこともない。

そういうわけで、このニクをとることは私にとっては不可能なことなのかもしれない。

一から構築してみようと思い立ったものの、何も進んでいない状態。
基本はJUCEの内部をお手本にするかな。
後は、Boostをできる限り活用して作成していくとするか。

ジェフの最終戦を観にフクアリに子供と３人で行った。
というのもアウェー側のチケットをもらったから。
大分のサポーターの中に混じり、観戦。
しかし野球と違ってアウェーはきついなあ。。

それはともかく、試合は２−０の完敗。

今のままのジェフだときつい。
というのも観ていて面白くないのだ。
やはり昔のジェフを知っているだけに、このようなパフォーマンスの低い試合を見るとどうなっちゃったの、ジェフ？と思ってしまう。
まあ、この状況でモチベーションを高めるのは選手も難しいだろうけど。。

今のチームを建て直すのは経験の浅い江尻監督では厳しいだろうね。経験豊富なコーチが必要だ。ヒディンク来てくれないかな。。無理か。。

とりあえずWidget自作で頑張ってみることにした。
思考ばかりで成果物ゼロ。

Direct2Dを生かしたWidgetライブラリを作ろうとしているけれど、難しいね。Direct2Dはオーナードローとかカスタムドローとか、既存のWin32コントロールの描画には適していないような気がする。
もし、Win32コントロールをDirect2Dで描画しようとすると、コントロール１つ１つにRenderTargetを作成しなくてはいけないからだ。１つのウィンドウをフレームバッファに見立ててコントロールを自前で描画したほうがよさそうだ。でもそうすると、Widgetはほぼスクラッチで作成しなくてはならない。
いやぁ、面倒くさいなぁ。。。

UI部分を自作してみようと思うものの、どう作ればよいかいまいちいいアイデアがうかばない。
で、Chromeのソースコードを見てみることに。
うーん結構泥臭いというかWin32 GDIしているなぁということがわかった。世の中そんなに甘くなかったことがわかったのである。
使うUIコントロールを限定してオーナードロー。描画APIはDirect2Dを使用してやる方向で行くことに。

ようやくウィンドウが表示され、文字が表示できた。


http://sourceforge.jp/projects/sftracker2/svn/view/sftracker2/?root=sftracker2

今日はWindowの基本的な部分の実装を行っていた。

最初に考えたのはHWNDとC++クラスインタンスとの結びつけなのだが、最初はWM_CREATE時に、SetWindowLongPtrのGWLP_USERDATAエリアにthisポインタを保存する方法でやってみたら、WM_CREATEイベント発生前にいろいろなメッセージが発生し、そのハンドリングに問題が生じることがわかったので、thunkを使うことにした。

アイデアは下記サイトから拝借した。
http://www.issei.org/blog/2007/12/good-bye-atl.html

xbyakを使って実装してみたところ、うまくいった。下記がそのコード。

		struct hwnd_this_thunk : public Xbyak::CodeGenerator {
			hwnd_this_thunk(impl* pimpl,WNDPROC proc)
			{
				push(eax);
				mov(eax,ptr[esp + 8]);
				mov(ptr[&(pimpl->hwnd_)],eax);
				mov(eax,(DWORD)pimpl);
				mov(ptr[esp + 8],eax);
				pop(eax);
				jmp(proc);
			}
		};

http://sourceforge.jp/projects/sftracker2/svn/view/sftracker2/?root=sftracker2

WASAPI+Direct2Dを使ってコードを作り直すことにした。
最初にWTLのような薄いGUIラッパクラスを作ってみることにする。
http://sourceforge.jp/projects/sftracker2/svn/view/sftracker2/?root=sftracker2

日本代表は今のところFIFAランク40位である。
その付近にはどんなチームがいるかというと、ガーナやトルコ、ボスニア・ヘルツェゴビナがいるが、そのチームはどんなチーム？と聞かれても僕は答えることができない。まあ、世界における日本代表の一般的な地名度ってそんなもので、印象にもあまり残らないのではないかと思う。オランダ戦をみてもそんなに人は入ってなかったしね。オランダに限らず、ヨーロッパで対日本戦を見たいなんていう人たちは、自国の熱狂的なサポーター以外はあまりいないのではないかと想像する。

Googleってすごいよね。

子供によくパパが小さいころはゲーム機なんてなくて、もっぱらメンコ（ベッタン）、ビー玉で遊んでいたんだよ、みたいな話をしていた。
で、メンコに関してはどういう遊び方をしていたのか話できるんだけれど、ビー玉に関してはルールを忘れてしまって、話をすることができない。
これが近いような気がするんだけど。。
http://blogs.yahoo.co.jp/kmwwy471/7129474.html

とりあえず音が鳴り、マイクが使えるようになったけれど、まだまだToDoが、、、。

・16bit以上のサンプルビット対応（24bit,32bit）
・96Khzサンプル周波数の対応（現状だとなぜか死ぬ）
・ボリュームコントロールAPIの利用
・Device Topology APIいじり

など、その他もろもろ。。

（参考）
http://msdn.microsoft.com/en-us/library/dd316780(VS.85).aspx

■オーディオAPIのユーザモードコンポーネント化

Core Audio APIはユーザモードコンポーネントとして実装されている。
これはカーネルモードで動作していた時にくらべて信頼性が向上するから。
Vista以降はDirectSoundやWindows Multimedia Functions などの高レベルAudioAPIはCore Audio APIを通じてオーディオデバイスにアクセスするように変更されている。

（参考：マイクロソフトの図）


■エンドポイントデバイスとは

物理デバイスを表現する抽象的なデバイスのことである。エンドポイントデバイスの例：スピーカ、ヘッドフォン、マイクなど
上図ではエンドポイントデバイスはオーディオアダプタに接続されたスピーカーセットである。

■エンドポイントバッファ

WASAPIはデータをエンドポイントバッファを通じてエンドポイントにデータを渡す。システムソフトウェアとハードウェアコンポーネントはエンドポイントバッファからエンドポイントデバイス間のデータ転送を行う。あとジャックに接続しているかどうか検出できるオーディオデバイスは、実際に出力可能なエンドポイントデバイスだけにエンドポイントバッファを作成できる。

■共有モードと排他モード

エンドポイントバッファは２つのモードがある。共有モードと排他モードである。
上図では共有モードと排他モード両方記載されているけれども、開くモードによって２つモードのうちいずれか１つのみが存在する。

まず共有モードは、他のプロセスで動作しているアプリケーションとオーディオハードウェアを共有する。共有モードでストリームをオープンした場合、エンドポイントバッファにオーディオデータを書き込むと、Windowsオーディオエンジンがエンドポイントバッファからデータを読み出す。そして、オーディオエンジンはアプリケーションのストリームをミックスしてハードウェアに送る。オーディオエンジンはストリーム処理を行うユーザモード・システムコンポーネント(Audiodg.dll)である。共有モードでは、オーディオエンジンによって使用されているミックスフォーマット（もしくはミックスフォーマットに近いフォーマット）を使用してストリームをオープンしなくてはならない。共有モード中ではオーディオエンジンの入力ストリームおよびエンジンからミックスされる出力はすべて同じフォーマットである。

※Windows7では、共有モードでlow-latecneモードが追加された。このモードだとオーディオエンジンはプルモードでの動作時の処理遅延を大幅に削減する。（それに対してイベントモードというのがあるのだけれど、これはまた後日。。）

次に排他モードは言葉通りオーディオハードウェアに排他的にアクセスすることができる。利用中は他ののアプリケーションの音は鳴らなくなる。排他モード中では、エンドポイントデバイスがサポートするオーディオフォーマットのなかから、オープンするフォーマットを選択できる。排他モードはレイテンシにシビアなDAWアプリケーションなどで使用する。

■MMCSS

低レイテンシなオーディオストリーム再生するアプリケーションが間断なくストリームを再生できるように、Windows VistaではMultimedia Class Scheduler Service (MMCSS)を使用することができる。MMCSSは低優先順位のアプリケーションへのCPUリソースの割り当てをなくすことなく高いプライオリティでアプリケーションを動作させることができる。MMCSSスレッドは、タスク名に基づいて優先順位を割り当てる。たとえば、Windows Vistaでは"Audio"と"Pro Audio"というタスク名をサポートしている。デフォルトでは"Pro Audio"の方が"Audio"よりも優先順位が高い。

■ストリームのフォーマット

Core Audio APIはPCMおよびnon-PCMストリームフォーマットをサポートしている。しかし、オーディオエンジンがミックスできるのはPCMストリームのみである。なので、排他モードだけがnon-PCMストリームフォーマットを設定することができる。

■オーディオエンジン&オーディオサービス

オーディオエンジンはアプリケーション中のプロセスから分離された保護プロセスで動作する。共有モードをサポートするためにWindowsオーディオサービスはオーディオエンジンとアプリケーションの両方からアクセス可能なcross-processエンドポイントバッファを割り当てる。
排他モードではエンドポイントバッファはアプリケーションおよびオーディオエンジン両方がアクセス可能なメモリ中に存在する。

■Windowsオーディオポリシー

オーディオポリシーはシステムが同じハードウェアの利用のために共有・競合する複数アプリケーションのオーデディオストリーム間の相互調停を行うための内部ルールのセットである。Windowsオーディオサービスはオーディオエンジンのための制御パラメータを設定することによってオーディオポリシーを実装する。←この辺今時点よくわかりません。

■Windows Audio サービス

オーディオサービスの役割は、

・ユーザがシステムからオーディオデバイスを削除・追加してもオーディオデバイスのトラックを維持すること
・システム中のオーディオデバイスが割り当てられる役割をモニタすること
・類似するオーディオ・コンテント(console, multimedia, and communications)のクラスを生成するタスクグループからオーディオストリームを管理すること←（意味不明）
・さまざまな種類のオーディオコンテントのそれぞれの複合出力ストリームの音量レベルを制御すること・オーディオストリームのためのデータパス中の処理エレメントについてオーディオエンジンに伝えること

■ドライバコンポーネントについて

上図中の"Audio Driver"と表記された部分はシステムとベンダで提供されたドライバコンポーネントの組み合わせで提供されることがある。
PCIもしくはPCI Express上のオーディオアダプタの場合、システムはPortクラスシステムドライバ(Portcls.sys、アダプタ中のさまざまなオーディオ機能ためのポートドライバのセットを実装している)を供給し、ハードウェアベンダはポートドライバのためのデバイス固有のオペレーションを操作するミニポートドライバのセットを実装する。PCIもしくはPCI Express上のHigh Definition Audioコントローラおよびコーデックでは、システムはアダプタドライバ(Hdaudio.sys)を提供し、ベンダ供給ドライバは不要である。USB上のオーディオデバイスの場合、システムはUSBオーディドライバ（usbaudio.sys）に加えてAVStreamクラスシステムドライバ(ks.sys)を供給し、ベンダ供給ドライバは不要である。

■キャプチャ（録音）ストリーム

Core Audio APIはキャプチャ（録音）ストリームも同様にサポートしている。共有モードではオーディオデバイスからのストリームをキャプチャを共有することができる。排他モードではオーディオデバイスからのキャプチャストリームを排他的にアクセスできる。

完全アウェーで、しかも南アフリカ選手のモチベーションも高い。
なかなかこんなシチュエーションで試合はできないので、本番を想定して望んでくれるのかーと思ったのだが、残念ながら前半で実験をしてしまったみたい。
南アフリカは個々の身体能力はすごいけど、テクニックはいまいちという感じだ。トラップミスやパスミスを連発していたけど、それを身体能力でカバーしていた感じ。

前半20分は日本代表もボールを回せていたけど、相変わらず得点のにおいがしない。南アフリカがディフェンスをしっかりやってきたから。そのうち慣れてくると南アフリカもボールを回して攻撃してきた。
パレイラ監督しては思いどおりのゲームプランだったのではないか。でもいかんせん選手のテクニックがなぁ。あれでは。監督がいくらすごい戦術を駆使してもカバーしきれないだろう。

僕としては日本代表のベストメンバーでどれくらい力があるか見てみたかったんだけど、中村俊輔が過密日程でコンディションが悪いこともあって、テスト的な試合になってしまったようだ。
まあ、ディフェンスをしっかりやられると今の日本では得点は期待できないのはわかったけど、ベストメンバーのパフォーマンスを見れるのはいつになるんだろうか。Ｗ杯本番まで見れないのかな。。やっぱり。