「 2013年04月 」一覧

BulletのVS2012ビルドを試みる


Bulletの 2.79バージョンをVisualStudio2012用ビルドしようとして試行錯誤した結果を書きます。
結局のところ、本家のSVNツリーから取得することになりましたが…。

ダウンロードした bullet-2.79-rev2440.zipを d:\testBullet に展開して
D:\testBullet\bullet-2.79 となるようにする。

CMakeを起動して、
Where is the source code: D:\testBullet\bullet-2.79
Where to build the binaries: D:\testBullet\bullet-2.79-build

そして、Configure ボタンを押す。
このときVisualStudioのバージョンを聞かれるので、Visual Studio 11 を選択。
(Visual Studio 11は Visual Studio 2012のことを指す)

今ほしいのはbulletのライブラリなので、デモの類いをビルド対象から外します。
BUILD_CPU_DEMOS, BUILD_DEMOS, BUILD_MINICL_OPENCL_DEMOS らにチェックが入っていればオフにします。

続いて、BUILD_EXTRAS, USE_DX11, USE_GLUT, USE_GRAPHICAL_BENCHMARK のチェックもオフにします。

一方でVisualStudioのランタイムDLLを使用する場合には、 USE_MSVC_RUNTIME_LIBRARY_DLL にチェックを入れます(今回はチェックした)。

設定できたら Configure ボタンを押して、Generate ボタンを押します。

先ほど指定したフォルダ(D:\testBullet\bullet-2.79-build)にプロジェクトが出来ているのでこれを開いてビルドを実行します。

本来ならここで、ビルド成功して終わりなのですが、このバージョンと上記の組み合わせではビルドに失敗します。

2>d:\testbullet\bullet-2.79\src\linearmath\btAlignedObjectArray.h(304): error C2719: 'CompareFunc': __declspec(align('16')) の仮引数は配置されません。
2>          D:\testBullet\bullet-2.79\src\LinearMath/btGrahamScan2dConvexHull.h(88) : コンパイルされたクラスの テンプレート のインスタンス化 'void btAlignedObjectArray::quickSortInternal(L,int,int)' の参照を確認してください
2>          with
2>          [
2>              T=GrahamVector2,
2>              L=btAngleCompareFunc
2>          ]

リポジトリからコードを取得する

パッチも提供されているようでしたが手元では簡単に適用して問題解決とならなかったため、rev2480を取得して対処しました。
このリビジョン2480は 2.79のビルドエラーに対応したパッチが適用されたものとなっているようです。

取得したソースツリーで、上記の手順を同じように行ってライブラリを生成します。


Device Topology API を使ってみる おまけ


前回の各処理ユニットの接続状況を調べていくプログラムを作成して、ちょっと気になったことがありました。
自分のもっているある環境では妙なことが起こったのです。それが、「ジャックの数と並んでいるチャンネルの数が一致しない」という挙動です。

これが前回にも使った環境なのですが、ジャックは3つで、ここからチャンネル数は 6と予想がつきます。

しかしこのスピーカーの各ボリュームを表示してみると、以下のようになります。

Side-LR が増えています。しかし、ジャックにはその情報がいないようで、謎です。
ドライバの問題でしょうか・・・。

そこでマニュアルを取り出してみると、 VT1718S というサウンドチップが使用されており、なんとこれは8ch出力も可能である旨が記載されていました。この場合、8chの最後の部分が Side L&R と割り当てられており、このときの出力線は line out が使用されるとありました。

この情報から、ジャック情報にはline outの情報が出ていないだけで、実は8chが使用可能であったということがわかりました。実際にスピーカーの構成で 7.1ch を選択してテストしてみると、確かにLineOutにつないだところが Side LRとして鳴りました。当然ながら、5.1ch構成にするとLineOutにつないだスピーカーからは音が出力されませんでした。

このプロパティのチャンネルの並びについてよくわからないのですが、チャンネル数だけがわかっているときには参考URLに示すように、デフォルト値と対応するようにして並んでいるのかな~と思います。

個数 暗黙的なチャンネル位置
1 両方のスピーカーの FrontLeft および FrontRight に常にフル スケールでマッピングされます (モノラル サウンドの特殊な場合)。
2 FrontLeft、FrontRight (基本的なステレオ構成)。
3 FrontLeft、FrontRight、LowFrequency (2.1 構成)。
4 FrontLeft、FrontRight、BackLeft、BackRight (4 チャンネル)。
5 FrontLeft、FrontRight、FrontCenter、SideLeft、SideRight (5.0 構成)。
6 FrontLeft、FrontRight、FrontCenter、LowFrequency、SideLeft、SideRight (5.1 構成)。
7 FrontLeft、FrontRight、FrontCenter、LowFrequency、SideLeft、SideRight、BackCenter (6.1 構成)。
8 FrontLeft、FrontRight、FrontCenter、LowFrequency、BackLeft、BackRight、SideLeft、SideRight (7.1 構成)。

参考: XAudio2 の既定のチャンネル マッピング


VisualStudio 2012 でのプロジェクトの依存関係


VisualStudioではプロジェクトの依存関係を設定すると、その設定された依存先が出力するライブラリを暗黙的にリンクしてくれる機能が、かつてはありました。VisualStudio 2008のころにはよくお世話になりました。
しかし、VisualStudio 2012で同じことをやってみても、どうもその暗黙的なリンク機能が働かないようです。
正確には、従来の手順だけでは働かないということだったのですが、今回はこの方法を記事にしたいと思います。
また今回の内容は 2010からの挙動変更のようです。

  1. 従来通り、依存関係を設定した複数のプロジェクトから構成されるソリューションを作成します。
  2. この中のアプリケーション側のプロジェクトのプロパティを開きます。
  3. 共通プロパティを開き、「新しい参照の追加」ボタンを押し、依存先のプロジェクトにチェックを入れる

この手順を行うことで、従来の挙動のような暗黙的なリンクを行うことが出来ます。

なお注意点として、この参照の追加で自分自身をいれないこと。入れてしまうとよくわからないエラーが発生してしまいます。


Device Topology API を使ってみる その2


前回はジャック情報を取得しました。今回はオーディオの各ユニットの接続状況を取得するプログラムを書いてみました。
各ユニットへのIN/OUTの情報をコンソールに出力します。

前回のプログラムを利用し、IPartインターフェースを取得できたところから、接続状況をたどっていきます。

このようなコードで、現在のIPartに対して、入力・出力のIPartListを取得し、接続状況を調査します。
入力も出力も情報そのものは同じなので、入力部分のコードだけ下記に示します。

情報取得の部分では、名前しか今は取得していないですが、接続の情報や処理ユニットのGUIDとか色々ととれる情報があるようです。


DeviceTopology API を使ってみる


Windows Core Audio APIの1部である DeviceTopology APIを使って、ジャック情報を表示するプログラムを作ってみました。
デフォルトの出力先としているデバイスのジャック情報をコンソールに出力します。

ジャックの情報はスピーカーのプロパティ等で確認することができます。

この情報をプログラム中で取得、表示ということをします。

デフォルトの出力先デバイス(IMMDeviceインターフェース)は取得できているとして、
これから IDeviceToplogyを取得し、そこに接続情報を示す IConnector インターフェースを取得します。

そしてさらにこのコネクタに接続しているコネクタを取得します。

この IConnector は、コンポーネント間の接続を表現するインターフェースです。
ジャックや各処理ユニットの接続状況がこのインターフェースを用いることで調べることが出来るようです。

そして、1処理ユニットを示すインターフェースが IPart となるようなので、これを IConnector より取得します。
取得するメソッドが見つからないので、COMコンポーネントのおきまりのQueryInterfaceで取り出しています。

ここまで取り出しが終わったら、 IKsJackDescription インターフェースを取得して、ジャック情報構造体を取得します。
取得したら各メンバについて表示を行っています。表示を行う関数については省略します。

今回作成したプログラム実行体をおいておきます。dispJackInfo


最近のWindowsのオーディオアーキテクチャについて( Windows Core Audio API)


Windows Vista以降のサウンド関連APIについて。
音質についてはあまりよくわからないので、調べてわかったを書いていきます。

まず、APIの説明がほぼ英語・・・。あまり英語が得意ではないためAPIを見て何となく試してみて理解ということをやってます。
その中、日本語で説明されているサイトを見つけました。

ttp://mikeo410.lv9.org/lumadcms/~programmingcoreaudiointerface
どうやらページが消えてしまったようです(2015/03/20)。

これだけでは全然足りないけど、一通りのインターフェースが日本語で書いてある数少ないサイトで、自分にはすごく参考になりました。
サウンド周りといえば WASAPI (Windows Audio Sessions API) がよく取り上げられていて、調べる際の検索キーワードで大事だけど、そこにはまだ関連するグループとして他のモジュールも存在して、これらをひっくるめて Windows Core Audio と呼ぶような感じです。このキーワードも調べる際に活用しないとわからない部分があるな~と思います。
XPのときと大幅に変わっているし、ハードウェアに近いところで制御しようと思ったらこれらが必要になります。

Windows Core Audio

  • MMDevice API
  • WASAPI
  • Device Topology API
  • EndpointVolume API

MMDevice API って何かとおもったら、Multimedia Device という意味で MMDeviceなんだそうだ。
WASAPIを使うことで低レイテンシでサウンドを鳴らしたり、Device Topology API 使ってスピーカーまでの接続状況を調べたりとか色々できるっぽい。これらについてはそのうち何かサンプルコードを書いてみようと思います。

そしてこれらCore Audio の位置づけは、リンク先の図によると、ユーザーアプリケーションが直接さわれる部分としてはカーネルモードに近いユーザーモードの部分かと。

参考: 楽しいハック講座(4) Windows7 オーディオアーキテクチャの概要


VisualStudio 2012とDirectX SDK 再び


以前の日記にて、Visual Studio 2012 と DirectX SDK (2010June) を使って開発する際の手順を書きましたが、
どうやら最近ではマイクロソフトのほうに注意書きが用意されているようです。

そのページがこちら(http://msdn.microsoft.com/en-us/library/windows/desktop/ee663275(v=vs.85).aspx)です。

基本的には、DXSDK_DIRのインクルードとライブラリを標準のものより優先されるようにすること、という以前の日記情報と同じです。
ただ上記URLの中身ではそれよりももうちょっと踏み込んで、手順が書いてありました。

  • コンフリクトするので DXGIType.h をインクルードしているコードを修正する(インクルードしないように)。
  • テクスチャ関連は DirectXTex や DirectXTK といったものを利用するように検討すること
  • 算術に関しては D3DX から DirectXMath の実装へ切り替えを検討すること
  • XInput や XAudio2 を使う場合には要注意

気になった点をざっと列挙してみました。
XAudio2は厄介そうです。 使用するDLLがVS2012とDXSDKとで異なってしまうようで・・・。
どこでも動くように、というならば DXSDKのものをつかわないといけない、ということのようです。


Androidネイティブデバッグ再び


Nsight Tegraがあまりに強力だったので、逆に標準のndk-gdbではどこまで出来るのだろうとテストしてみることにしました。

以前にLinux(Ubuntsu)環境でAndroid開発用の環境を作った記事(ここ)がありました。この環境を使ってテストしてみます。
当時はNDK r8bを使用していましたが、あれから結構時間も経ったので進化している部分もあると思い、現在の最新 NDK r8e を用いてみることにしました。

以前でもブレークポイントはひとまず張れること、変数がみれることは確認していました。
そこで Nsightで出来たことが ndk-gdb では出来るかという点で見てみたいと思います。

Jni Proxyタイプのアプリケーションで、ネイティブアプリ側にブレークポイントを指定できるか?

いきなり一番難しいケースにトライしてみます。これが出来ればかなり優秀かと。
以前はコツがあったのですが、今回はそれ無しでいきなりブレークポイント指定してみます。

ソースコードは先日のものを使用し、ネイティブアプリ側のapp_init関数にブレークポイントを指定してみます。
Java側でjniInitを呼ぶ直前でブレークポイントを設定してデバッグ実行し、停止した後で ndk-gdb を起動してみます。
このあたりはいつもの手順となっています。

ndk-gdbを起動した後で、ブレークポイントを指定しますが、このときネイティブアプリ側のsoがまだロードされていません。そのためロードされたときにブレークポイントが指定されるよう、pendingの問い合わせについては “y” を答えてあります。

この後、”c” で実行を継続し、Java側でも実行継続させて、ブレークポイントで停止するかどうかを見てみたいと思います。

・・・

無事に停止しました!!!以前はそれなりに大変だったのになかなかやるじゃないか ndk-gdb

メモリの表示と変数の表示について

JniProxyタイプのデバッグがNsight Tegraで出来たことで最強と思っていたので、ndk-gdbが出来るとは思っていませんでした。
なかなかやりおるのでコード追加して、前回NVIDIA Nsight Tegraで確認したメモリ表示や変数の表示についてチェックしてみたいと思います。

1つめのforが終わったところで v の中身やメモリ番地の中身を覗いて見た図。無事に変数やその確保したメモリの周辺状況を見ることが出来ています。

続いて、Nsight Tegraで出来なかった動的確保配列の中身表示と条件付きブレークポイント。
以下のように、うまく動作していることがわかります。
(条件付きで止まったことを確認するため、i の値を最後に確認してます)

逆アセンブルも出してみる。

gdbなのでコマンドを叩く手間はありますが、うまく動いているようです。
ここまで動いていたので、いざeclipseでソースコード見ながらステップ実行、としてみました。
ただ若干不安定で関数のステップインの挙動が怪しい状態でした。ndk-gdb直接触っていたらうまく動くのに。
機能的にはgdbが備えていてもそれをユーザーフレンドリーに操作する部分はまだまだのようです。

そういえば、ADTの新しい物は NDKのデバッグもサポートしたとか話があったので、最新状態で環境構築して再度トライしたらこの問題解決していたりしないかな~とおもっている次第です。


NVIDIA Nsight Tegra がすごい その5


あれからもうちょっとだけ、Nsight Tegra を触ってみました。
今回はデバッグによく使うであろう機能についてチェックしてみます。

ブレークポイントが張れて停止するのは今までにしっかりと確認してきました。
今回は、条件付きブレークポイントやメモリ領域の表示、使い慣れたVisualStudioでの変数表示形式指定などを見てみたいと思います。

早速下記のコードを書いてチェックしてみました。

まずメモリ領域の表示について。これは v を確保したときに、メモリウィンドウで表示させてみました。

メモリの表示はうまく動いているようです。
しかし、ウォッチウィンドウでポインタを要素数指定して配列のように表示する機能については、うまく機能しないようです。
画像では、”v,10″としていますが、配列表示できていないことがわかります。

続いて条件付きブレークポイント。
2つめのforの中で、i == 6 の時にブレークするようにして実行してみました。
このときは以下の画像のような結果となり、条件で停止してくれませんでした。

Visual Studioのデバッガを深く慣れていて機能を使いこなしている人にとっては、ちょっと不満が残りそうです。
その一方で、単純にブレーク設定できればいいという人にとっては十分役立ってくれそうです。

gdb を直接触るタイプ(ndk-gdb)との差が付いてきてしまったように感じました。
そこでそろそろndk-gdbでは今現在どのくらい使い物になるのか、確かめてみたいと思います。


USB 3.0 Kernel Debugging のための準備


Windows8 で カーネルデバッグを行うのに USB 3.0 が使えます。
ただしこのUSB 3.0で接続をするには、PCとPCを USBケーブルで接続しないといけません。
そして、PCは基本的にホスト側であることを想定されているため、タイプA形状のコネクタを持っています。
つまり、A-Aのケーブルが必要になります。

今までの USB 2.0 の場合は、特殊な機器を購入してそこに2台からのUSBケーブルを差し込む形になっていたようです。

さて、この接続するためのケーブルについてが特殊なので今回のネタとなっています。
WinDbgのヘルプには、こうあります。
「A USB 3.0 debug cable. This is an A-A crossover cable that has only the USB 3.0 lines and no Vbus」

これを読み解くと、USB3のラインだけ接続されたクロスオーバーのデバッグケーブルで、接続するとなります。
また、色々と調べてみてわかったのですが Universal Serial Bus Specification を紐解くとターゲットOSのデバッグ用の接続についても考慮された仕様が決められていました。
これらの情報から、デバッグケーブルを自作してみました。

デバッグケーブルを自作する

ケーブルの一部を切り開いて加工し、最後に一応シールド用としてアルミを当ててそっとケーブルを閉じてみました。

こうやって作成したケーブルで試したところ、先日のWindows8をターゲットとしてWindows Kernel Debugができた、というわけです。

簡単にケーブルを作成していますが、この状況にもっていくまでに何本かは失敗しています。
シールドの問題や、加工のしやすさ(&慣れ)、といった部分から失敗前提でチャレンジが必要かもしれません。
自作にチャレンジされる方は、パーツ数に余裕を持っておいたほうがよいとおもいます。

使用したもの

加工に向いたケーブルがなかなか見つかりませんでした。上記のものは amazon で購入した以下のケーブルを使っています