スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 少し本題に入った | トップページ | 恐ろしいというよりは・・・ »

一抹の不安はあるが

今はAmuseGraphicsの開発フェーズで、Ver1.3.1で積み残したレジストユーザー向けのプレミアムソフトを継続開発しているのだが、予定している2つの中で、とりあえず、簡単に出来上がりそうなDirectShowに音声を出力するオーディオミキサーを作り始めている。

オーディオミキサーは、通常の録音デバイスと再生デバイスからのループバック音声をミックスして、DirectShowの音声入力を受け付けるソフトに出力する格好になる。

で、再生デバイスからのループバック音声というのは、Windows Vistaで追加されたCoreAudioの機能を使って取得するのだが、通常の録音デバイスからのデータ取得方法は幾つかある。

その一つは、大昔からあるマルチメディアAPIを利用する方法で、WaveClipperでは、このAPIを使用している。もう一つの方法としては、DirectShowのAPIを利用する方法で、AG-デスクトップレコーダー/AG-Webカメラレコーダーでは、このAPIを使用している。

もっとも、録音デバイスからの音声入力方法としては、DirectSoundを利用する方法もあって、更には、前述のCoreAudioでは素直に録音デバイスからの音声をキャプチャーする事も出来る訳だ。

と、いう事で、作者的には、既存ソフトで利用しているAPIを使う方が楽と言えば楽かもしれないのだが、今回開発しているオーディオミキサーのコア部分は、DirectShowのグラフ内で動作するフィルターになる訳なので、DirectShow経由でデータを入力するというのは、危なっかしい気もする訳だ。

なので、WaveClipperで使っているマルチメディアAPIを使おうかなあ、とも思ったのだが、このAPIを使おうとすると少し複雑な構成にならざるを得ないので、複数の音声パスを扱う必要があるオーディオミキサー、しかも、DirectShowフィルター内では、使いたくない気もした訳だ。

更に言えば、このマルチメディアAPIでのデータ取得では、コンマ数秒程度の遅延は覚悟する必要があるので、今回は、出来れば、使わない格好にしようと思っている。

そうすると、使用できるAPIとしては、DirectSoundかCoreAudioになる訳なのだが、今となっては、DirectSoundというのは、CoreAudioのラッパー扱いになっている。

つまり、処理性能的には、CoreAudioを使うのがベストだし、どの道、ループバック音声用にはCoreAudioを使うので、録音用デバイスからの音声入力にも、CoreAudioを使って見る事にした訳だ。

で、今日、それをやってみたのだが、作者の手持ち環境にある録音デバイスは幾つかしかないのだが、CoreAudioで録音しようとすると、CoreAudioのAPIには音声データのフォーマットを変換してくれるAPIもあるのだが、それを使っても、作者が望むPCM形式には変換してくれなかった訳だ。

それでは、それらのデバイスはどういうフォーマットで音声データを出力してくるのか、というのを調べてみた所、あるデバイスは、WaveFormatEx形式で、別のデバイスは、WaveFormatExtensible形式で、形式を返してきた。

もっとも、双方共、本質的な形式としては、IEEE_FLOAT形式を使っていた。

で、作者の処理ルーチンの中では、音声データは、PCM形式で扱っているので、録音デバイスがIEEE_FLOAT形式で音声を出力してきた場合には、それをPCM形式に変換する処理ルーチンが動作する様にして、確認してみた所、作者環境では、全録音デバイスから正しく音声が録音できる事が確認できた。

と、いう事で、一応、PCMとIEEE_FLOAT形式に対応させておけば、CoreAudioを使った録音も可能かなあ、と、思われるので、前述のオーディオミキサーでは、録音デバイスからの音声入力についても、CoreAudioを使おうかなあ、と、思っている。

しかし、PCM以外の形式で音声出力してくるデバイスが普通にある、という事は、それ以外の形式で音声出力してくるデバイスも、ある可能性がある訳だ。

具体的には、この前のWindows10のアニバーサリーアップデートでは、メジャー処のWebカメラが利用できなくなった、というのが話題になったのだが、これは、Webカメラからの映像入力形式として、元々は、MJPEGとH.264もサポートしていたのだが、それらのデコードは重いので、Windowsの動作を軽くしたいMSとしては、APIのサポートを廃止してしまったからだ。

逆に言うと、音声入力についても、MP3やAACなんて形式でデータ出力してくる非常識なデバイスも存在するかもしれないので、作者的には、一抹の不安がある訳なのだが、今回開発しているオーディオミキサーでは、そんな形式で出力してくるデバイスからは、音声入力できなくする対処だけを入れておこうか、と、思っている。

ちなみに、前述のマルチメディアAPIを使った場合、データ形式は確実にPCMに変換されてから出力されるので、安全だ。

なので、最終的には、こちらに切り替える可能性もあるのだが、両方を実装しておき、デフォルトはCoreAudioにしておいて、問題が出たら、マルチメディアAPIを使って下さい、みたいな格好にしておく可能性もある。

更に言えば、音声キャプチャー処理はDirectShowフィルターの外部のサービスに移動させ、そこで、実績のあるDirectShow経由の音声入力を行い、ミキシング結果をDirectShowフィルターにプロセス間通信で渡す、という手もある。

実際の所としては、この方式が最も確実で、DirectShowキャプチャーデバイスも、ミキサーの入力に入れられるので、機能的にもベストなのだが、構成的に大げさになるので、今の所は、そういう形式にはしないでおこうと思っている訳だ。

= この記事に関連する公開中ソフト =

AGM Audio Mixer (AmuseGraphics)

AGMAMixer

(2016/10/25追加)

« 少し本題に入った | トップページ | 恐ろしいというよりは・・・ »

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/534482/64213365

この記事へのトラックバック一覧です: 一抹の不安はあるが:

« 少し本題に入った | トップページ | 恐ろしいというよりは・・・ »

2017年9月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    Cookieを無効にする設定およびAdsenseに関する詳細については、以下のリンクを参照下さい。

    広告 - ポリシーと規約 - Google