ほげぐらまの別館

前回の妄想編、の続きです。話の流れはこちらとも関連します。話の流れで言えば以下の感じ。

1. う～ん、物理デバイスが無いとHtper-V上の仮想OSでサウンドがストリームされないよ…
2. 解決策が見当たらないし。Technetサポートを使ってみよう！
3. 折角だし、blogの記事として起こしてみるか・・・、あれ？ひょっとして解決策が見つかった・・・？ (妄想編)
4. 実験したら予想が的中しちゃったよ・・・、MSさんごめんなさい。メールでまとめて送ります・・・ (反省編)
5. MSさんから返答が来たのでまとめるか～・・・ (←今ここ)

 

結果も何も答えは既に妄想編に書いてあるように物理デバイスを持たないデバイスドライバを追加してあげる、ということです。そもそもWindowsアーキテクチャと3rdパーティーが実装するであろうリモート接続環境の方法を妄想すれば自明なことだったのかもしれません。

3rdパーティのリモート接続環境がオーディオストリームをフックする為に予想される場所は2箇所。

• オーディオ操作のためのWin32APIをフックする (Win32API Hook)
• オーディオ出力のためのデバイスをフックする (上位のClass Filter Driver)

つまりはハードウェアレイヤーより上位のレイヤーによる部分で実装されているはず・・・なのです。となれば、妄想通り3rdパーティのリモート接続環境がフックするための物理デバイスを要しないデバイスドライバを追加してあげればサウンドのストリームがされるはず、と。

ただ、前回も書いたようにこれを自前で用意するとなると非常に苦痛な作業で、これも探してこようと。で、見つかったのが”Virtual Audio Cable”というデバイスドライバ。内容的には、各種サウンドデバイスをPin接続する(KSProxyのPinを内部的に切り替えている、のだと推測します)というのを仲介するっぽいです。ググった感じではネットラジオやニコ生放送で内部出力(ヘッドフォンetc)と外部出力(ストリーミング)を1音源から行いたい場合に使うようです。もちろん、今回はそんな用途とは全く別の使い方をしますが。

VACは評価版があるようで、評価の場合に以下の制約を受けるそうです。

• 内部的なケーブルとして3ケーブル分しか使えません
• 数秒ごとに女性の声で”Trial”というボイスが挿入されます

 

インストールは簡単、VACのサイトからダウンロードして展開すると”setup.exe”があります。x86, x64のどちらの環境も”setup.exe”でインストールをしましょう。VACのページにも再三警告がありますが、以前のバージョンがインストールされている場合は必ずアンインストールしてね、という警告があります。そもそも今回はHyper-V上のゲストOSに対するインストールなのでHyper-Vらしくスナップショットを事前に取っておきましょう。

 

途中で信用できない発行元からのデバイスドライバをインストールするかどうか、の確認が表示されます。もちろんここは信頼してインストールします。

 

インストールが終わったら一旦再起動します。再起動は聞かれていませんが、再起動しないと何故か再生ミキサーに出現しないし、何より再起動することで安心できますよね。再起動後は既にVACがデバイスとして有効となっているのでいよいよiPadからの”Splashtop Remote Desktop”を経由した接続テストです。

 

図にあるように、音量ミキサーを開いてサウンドをミュートから鳴音(めいおん)状態へ変更します (1月6日訂正)ミュート状態でもリモートサウンドが再生できました、VACデバイスのゲインが上下に振れていれば出るっポイです。後は、ZuneなりiTunesなりお好きなミュージックソフトウェアからテストをします。きっとサウンドが聞こえるでしょう。

 

以上で、Hyper-V上のゲストOSから”Splashtop Remote Desktop”を使用してサウンドストリームをリダイレクションする方法の一連となります。これによってより一層Hyper-Vによるクライアント仮想化とモバイルデバイスという2つの技術に価値が見出せたのかなと。さて、ここで忘れてはいけない2つの部分を書いておきます。

 

1. VACのトライアル版って”Trial”みたいな音声が邪魔にならない？

今回の方法ではトライアル版での使用でも”Trial”という女性のは再生されません。というのも、”Splashtop Streamer”がサウンドストリームをフックしているのは恐らく入力側であり、”Trial”という声を入れるのはVACの出力側であろうと推測されるからです。が、しかしDonateだと思って購入しましょう。

特に自分の場合は独学でデバドラをかじったこともあり、あの苦痛ともいえるプログラムを製品まで持っていったプログラマを心から評価したいと思っています。意味不明なブルーバックのオンパレードは心をへし折るには十分すぎました(実際は意味があるんです、BSoDというあの画面には。でも、理解が乏しいと本当に意味不明なんです)。

 

2. Technetサポートから得られた情報は？

結果的にホストOSの物理デバイスを恒久的にゲストOSに割り当てる方法は無いらしいが、Windows7上のVirtualPCを用いれば割り当ては可能、だとのことでした(KBとしての資料ではないので確約が無いことは悪しからず)。今回はあくまでHyper-Vが前提となるのでこれを用いることはできませんが、覚えておこう、っと。Hyper-V3.0ではきっと恒久的なデバイスの割り当てができるよね？って期待を念押ししてサポート終了となりました。

※ サポート段階では知らなかったのですが、今ざっと見た感じではFiber, NUMAなどの複数台PCによる処理系が強化されているっぽいのかな・・・。物理デバイスの割り当ては無さそうな感じですね。まだ、Developer Previewのようなので、更なる機能追加に期待します。

(このblog投稿は12月23日に書かれたものです。理由はこちらを参照)

 

恐らく今回の記事に関しては誰得なのかサッパリわからないレベルですが、稀なケースでしょうというものです。タイトル通り”RemoteFX USB”と”リモートサウンド”と”Splashtop Remote Desktop”の3者が関連する微妙な疑問です。

RemoteFXを使い始めて1.5ヶ月ほどですが、幾つかの問題のうちの一つにSplashtop Remote接続時にサウンドが再生されないというものがあります。なぜ再生されないか、というのは一言でいえばHyper-V上のゲストOSに対しては仮想デバイスとしてのサウンドボードが割り当たらないのでSplashtop Remoteがフックするオーディオデバイスが存在しないことを意味します。

この裏付け確認として実験してみました。

• ホストOSの物理デバイスに”USB Audio”デバイスを接続
• ホストOSよりゲストデバイスに”RemoteFX USB”を通じて”USB Audio”を転送 (但し、サウンドはリモート側で再生する)
• ゲストOSの再生デバイスを”USB Audio”を選択する
• 上記の状態で、VPN経由をしたiPad2より”Splashtop Remote Desktop”でゲストOSに接続する

この状態であれば”Splashtop Streamer”が”USB Audio”のオーディオデバイスをフックすることでiPad2上の”Slpashtop Remote Desktop”でもサウンドが再生されるわけです。しかし、(ホスト・ゲストOSが同一の物理PC上で接続する限り通常はあり得ないが)ホストOSからの”Remote Desktop”が切断される＝”RemoteFX USB”が切断されるとオーディオデバイスも当然消えます。結果、再生できないと。

もちろん、Hyper-Vをこんな形で使おうなどというユーザが極稀であることは認識していますが、仮に今回のオーディオデバイス以外でもホストOSに接続した物理デバイスをRDPセッションが存在しない間も接続しておきたい、ということはあるのではないかなと、思ったり思ったり。ということで、まとめた結果”Hyper-V 2.1 permanently assign Guest OS”あたりでググったりしてみましたが結果は実りませんでした。それどころか、USBのみならずPCIをゲストOSにマウントしたいとか・・・。ここまでくると何でもありですね。別の仮想化環境として”VMWare ESX”がありますがこれならできるとかできないとか、でも製品、仮想化を行うための物理環境が共に高くて手を出せないです。

さて、文字ではいささか退屈なので図でまとめるとこんな感じ。まずはネットワークとしての全体像です。すんごい適当ですが・・・。

 

次に、”RemoteFX USB”でオーディオデバイスを転送していない状態でのデバイスマネージャ画面です。RDPで接続していますので、リモートサウンドが使える＝サウンドの再生は可能ですが、デバイスとしてのオーディオデバイスは存在していません。

 

そして、玄人志向から数年前に発売されていたUSBオーディオをホストOSに刺して”RemoteFX USB”を経由して接続する画面。”USB Audio”として認識され、ディスクデバイスのみならず転送できるところが魅力ですね。

 

最後に上記の”USB Audio”を有効にしてゲストOSに接続した状態。もちろん、この状態が”Hyper-V 2.1上のゲストOSに対してSlpashtop Remote Desktopから接続を行ってもサウンドがリモート側で流れる”という環境になります。

※ 画像がTypoちゃったけど、直すの面倒だから許して・・・。”RemoteFX USB”です。

 

現状では”Slpashtop Streamer”がどのレイヤー(API Hook, Class Driver, etc…)をフックしているのかわかりません。ただ、現状ではデバイスマネージャ上のオーディオデバイスが存在していないとゲスト側でサウンドが鳴らない、というのは確かというだけです。

 

ということは・・・、物理デバイスを要しない”(仮想の)何もしない再生サウンドデバイスドライバ”を作ってあげれば”Slpashtop Streamer”がフックするインターフェースを提供できるのでは！！！！　ということになるのかな、妄想レベルでは。確かにDDKでもWDKでもVideoCapという仮想のビデオキャプチャデバイスをインストールするサンプルがありましたね。また・・・・DDKですか・・・？、もう2年以上触ってないので勘弁してください・・・・。

※ “仮想の”というのをカッコ付で書いた理由は、確かOSレイヤからみて物理デバイスが存在するかどうかは関係なかったはずなので。言い換えれば、OSレイヤからしてみればドライバとして認識するかどうかが重要であって、ドライバが物理デバイスにI/Oを発行するか、は関知しなかった・・・・ハズ・・・。間違っていたらごめんなさい。記事のまとめが私の妄想ワールドで終わるのはこのblogの恒例行事なので許してください。