形を整えた
MSVAD応用のVtAudPlusについては、インストール用Infファイルやリソースファイルを変更して名称やレジストリのサービス名やバージョン/著作権情報を変更した。で、SaveDataクラスも排除して、最終形を作りこんで行ける状態に持っていった。
« 2009年11月 | トップページ | 2010年1月 »
MSVAD応用のVtAudPlusについては、インストール用Infファイルやリソースファイルを変更して名称やレジストリのサービス名やバージョン/著作権情報を変更した。で、SaveDataクラスも排除して、最終形を作りこんで行ける状態に持っていった。
作者環境ではMSVADベースのドライバとユーザーモードアプリとの通信が行えるようになり、このドライバに対して再生された音声をユーザーモードアプリで読み出してリアルなデバイスで再生できるところまで来ている。ドライバとの通信にはDeviceIoControlを使っている。
なにげなくココログニュースを見ていると、気候データ改ざん疑惑に反響という記事があったのだが、イマイチ判らず、ネットで調べてみたところ、「クライメートゲイト事件」というのがあったらしい。さらに調べていくと、嫌な雰囲気になってきたので調べるのは止めたのだが、一応、記事にしておく。
このブログの読者の多くは、普通のアプリで作成したメモリを他アプリからアクセスするのは簡単ではないことは理解しているだろう。また、その為に、Windowsがアプリ間でメモリを共有する手段を提供していることも。では、ドライバとアプリ間ではどうするのだろう?
意味の無いことばかり書いていると開発日誌ではなくなってしまうので、今日は、MSVADのデバイス名取得をInstallation Functionで行なう方法の概要を書いてみた。AC97サンプルにある方法と同じなので、詳細についてはAC97を参照して欲しい。
ガリレオが使った意味とは違うのだが、このブログへのアクセス解析を見ているとそう思える。このブログは開発ソフトの技術ネタがメインなのだが、それ以外にも雑多なことを書いてきている。なので、読者のアクセスも雑多だ。で、休日はWindows7からのアクセスが増えてきた。
MSVADについてはDDKのインストール関連ドキュメントを読んだり、処理を試したりしていたので書くべきことが無い。で、「PC Watch」に大容量HDDがOSの64bit化を招く という至極まっとうな記事を見つけたので、今日は作者の天邪鬼的な感想を書いてみることにする。
苦労させられたが、MSVADへのDeviceIoControlは何とかなりそうだ。とりあえず、今日の所はCreateFileでファイル名の指定が行えるようになり、得られたデバイスハンドルを使ってDeviceIoControlでドライバからプロパティデータを読み出せるようになった。
MSVADに対してDeviceioControlを使おうとしたのだが、DDKを見ていてもデバイスハンドルを取得する方法が見つからなかった。DDKにはユーザーモードからDeviceioControlで通信できる旨の記述はあるのだがCreateFileのファイル名指定方法については説明されていない。
ドライバはカーネルモードで動くので、デバックはそれなりの環境を作らないと困難なのだが、昨日書いた動作上の問題はMSVADのバグだということが検証できた。その作業中に色々とルーチンを弄ったので全体動作も把握できた。応用はさほど困難ではなさそうだ。
MSVADのコードを真面目に見てみたのだが、処理の全体像がまだ把握できない。オーディオドライバはCOMで構築されていて個別ドライバは些細なインタフェースを実装しているだけだからだ。こういう形だとコーディング量は減るかもしれないが、トラブルは増えそうだ。
数日前にXPでは仮想サウンドドライバを使えれば便利だ、と、言う旨の話を書いたのだが、DDKにMSVADという仮想サウンドドライバのサンプルがあったのでビルドしてみた。ものが物だけに、インストールしても何も起きないのだが、使えそうなら何かを作っておくつもりだ。
Linuxをインストールする自作PCを組んでみようか、ということで、ネットで検索してみたのだが、昔と違って、リスクが高そうに感じた。昔はマザーボードには大したチップは乗っていなかったが、今は違う。最新マザーは危険そうだが、古いマザーは手に入るのか?
ここのところ色々と書いているのは、来年は非Windows環境でも何かやりたいと思っているからだ。で、作者は喫煙者なのでApple製品はもう買えない。残るはLinuxとなるのだが、モバイル環境はauのAndroid携帯待ちだ。なので、当面はPC環境を何とかしなければならない。
古いdynabookがついに壊れた。そろそろ壊れるか、と思っていたので、MacBookの時のように呆然自失にはなっていないが、嫌なタイミングで壊れてくれた。作者は今、XPが必要なのだが、XPが動く実機はこれしか残っていなかったのだ。なのでVirtualPC2007とXPモードを使ってみたのだが、どちらも、一般的な実機とは互換性が無いのであまり役には立たない。
一時期、AppleのiPhoneが話題になったりもしたが、日本ではスマートフォンの普及率は低い。その理由は、携帯電話が高機能だからだろう。少なくとも、作者はiPhoneを欲しいとは思わなかった。しかし、Android携帯には注目している。スマートフォンが普及するとしたら本命はこれだろう。日本では各社が本格参入する来年からスマートフォン市場が賑わい出すのかもしれない。
タイトルが長くなると見づらいので省略したが、本当のタイトルはアプリケーションプラットフォームだ。今日はただの感想文なので、本文は見なくても良いかもしれない。今後、アプリケーションプラットフォームはどうなっていくのかな、と、何となく思ったことを書いてみただけだ。
このブログへのアクセス比率を見ていても、Windows7は急速にシェアを伸ばしてきてはいるのだが、XPの比率も未だに過半数を下回ることがない。作者としては複数OSのサポートは面倒なので古いOSは駆逐されて欲しいのだが、考えてみるとVistaや7はXPの代用にはなり得ない。なので、XPは10年後にも仮想環境で利用されているのかもしれない。
Mirror-DTCの開発時に無線LANでパケットロスが発生する、と書いたのだが、マルチキャストで使うと、遥かに多くのパケットロスが発生する。ユニキャストでは無線LAN機器が自動的にリトライを行なってくれるのだが、マルチキャスト時にはリトライは行なわれないからだ。
複数の受信者にパケットを送信する場合には、マルチキャストを使うのが正解であって、ブロードキャストを使うのはもってのほか、と、力説する人もいるかもしれないが、その人が説明するマルチキャストのメリットを鵜呑みにしていると、痛い目に合うかもしれない。
一昨日、画像配信用のマルチキャストパケットを無線LANに流し続けていると、と、書いたのだが、これは、劣悪な環境下でも使えるマルチキャスト画像配信プログラムを作っていたので、敢えて劣悪な環境となる無線LANで動作検証を行なっていたからだ。無線LANでマルチキャストを使うなんて、と思った人は優秀だ。しかし、作者も色々と考えて行動しているのだ。
AmuseGraphicsの改良開発を行なっているのだが、ブログとは関係の無いところで色々とやっているので、中々、先に進めない。頑張ってみても良いのだが、今年ももう残り僅かなので、あまりやる気にもならない。なので、多分、Ver1.0.2は来年に持ち越すことになるだろう。
dynabook MX/33を購入した時に無線LANは少し不安定、と、書いていたのだが、致命的でもなかったので放っておいた。しかし、ユニボディMacBookを購入し、11nが使えるマシンが増えたので比較して見てみたところ、dynabook MX/33の挙動が少しオカシイことが判った。
今日はあまり書くことがないので、追々調べてみると書いていた、ギガビットイーサーの性能について判ったことだけ書いてみる。とりあえず、スイッチングハブは無関係のようで、性能制限される問題はVistaに原因があるようだ。もっとも、これは仕様なのかもしれないが。
AmuseGraphicsのデスクトップレコーダーの改良開発中なのだが、内部的な性能向上はともかくとして、変則ストライピングについては、最適な設定を行えるようにすると、マニアックになりすぎる気がしたので、見た目には二つ目のワークファイルを指定できるだけにした。
デスクトップレコーダーで変則ストライピングを使用して性能を測ってみたところ、1280x1024画面で30FPSは普通に出た。しかし、巨大なバッファリングファイルを使用する影響からか録画後に膨大な数のsvchostが発生してHDDを唸らせた。多分、ディスクキャッシュの問題だ。
複数HDDへの変則ストライピングルーチンはほぼ出来上がったのだが、まだ、細かい調整を行なえていない。開発マシンのHDDが性能を出せる状態では無かったからだ。不覚にも、増設HDDへのインデックス付加を禁止するのを忘れていた。
AmuseGraphicsのデスクトップレコーダーで無圧縮バッファリングを行なう機能を追加しているが、大画面の高FPS取り込み時にはデータレートが100MB/Secを超えるため、HDDが1台では足りない。なので2台を前提とするが、ストライピングには変則処理を導入する。
デスクトップレコーダーでの録画を完全な無圧縮でやってみたところ、HDDへの書き込み量が大幅に増加した。そのこと自体は計算通りで良いのだが、色々と操作しているとSSDで有名なプチフリーズ現象が多発した。書き込み先を増設HDDにすれば問題は出ないのだが。
AmuseGraphicsのバージョンアップ開発を再開しようとしたのだが、元々1W以上も中断させる気はなかったので、コード変更を中途半端なところで止めている部分があって少し手こずった。今日の所は、何処までやっていたのかを確認し、普通に動くように戻した。
今日はギガビットイーサーの利用法を考えていたのだが、何気なく開発マシンからMacBookにファイル転送してみると15MB/Sec程度しか出なかった。で、マシン2台とHubの電源を落として立ち上げなおしたら100MB/Sオーバーのレートに戻った。しかしなあ、という感じだ。