QuadrupleD の DirectSound

QuadrupleD の DirectSound 周りの実装は色々と危ない香りがする。

まず最初に TDDSDCapture の問題。このクラスは一般的にはあまり使われるものではないと思うのでバグを持っているのは仕方がない部分ではあるのだが、相当前にQD3 の正誤表に書いた通りこのクラスにはリソースリークがある。
しかし実はその他に私は原因を発見出来なかった問題があって、このクラスを使うと不定期のタイミングでプログラムが例外を起こして止まる事があるように思える。これは原因がどこにあるのかハッキリと確証が持てなかったので Wiki では言及しなかったのだが、このコンポーネントを使用していると思われるねとらじステーションでは配信中にエラーを起こす問題があるという掲示板の書き込みを見た記憶があるので、恐らく何か抱えているだろうと思う。
実際自分で TDDSDCapture を用いて OggVorbis をリアルタイムレコーディング＋エンコーディングするツールを作った時にも不定期のタイミングで落ちる問題が起きていて、その時に自分で似たようなクラスを作り直した（ちなみに予想はつくと思うのだが、このツールでの経験をもとに CompactFM を作っている）。
それ以来同じトラブルにはまだ遭遇していない。

もうひとつ、さり気ないながら致命的な問題がある。
検索してみると過去に同じ事例があったようなのだが、QuadrupleD の DirectSound ヘッダを組み込むと ShellExecute の呼び出しが失敗するようになるらしい。
QuadrupleD に付属している DirectX のヘッダファイルは参照カウンタの扱いが特殊になっていて、自分で Release などを呼ぶ事でインスタンスの管理をしなければならないようになっている。それに関連しているのか、いくつかの場所で厄介な構造になっている事に起因しているのかも知れない。
この問題は Clootie graphics pages にて配布されているヘッダファイルを利用する事で解決できた。このヘッダファイルでは特に特殊なことはせずに素直に関数と構造体と定数を宣言しているようで、一部引数が var とポインタで違いがある部分や、参照カウンタを自前で扱う必要がなくなったので Release の呼び出しを削除するなど一部コードの修正が必要になったが問題自体は解消できた。
DDPD でもこのヘッダを使うと問題が解決することがあるらしい（未確認）ので、悩むことがあったらヘッダファイルの差し替えを検討してみるといいかも知れない。

TDDSD など頻繁に使われるコンポーネントは問題が露呈しやすく見つかっても大体すぐ修正されると思うのだが、TDDSDCapture など特殊な用途でなければあまり使われないクラスの場合は問題が見つかりにくいのだろう。
また、ShellExecute の場合もゲームなどの場合あまり使うことがないので恐らくあまり気付かれないままずっと使われてきたのだと思う。

以前不定期のタイミングで落ちるトラブルに遭遇した時点で TDDSDCapture を使うのは止めたのでこれ以上の問題追求や修正などを行うつもりはないが、今後同じトラブルに遭遇する人が出た時のために、一応こういう形で明文化しておくことにした。
この記事が役に立つと嬉しい。

CompactFM にあるといいもの

相変わらず妄想段階から抜け出さないのだが、どんな機能があればいいのか考えたりしている。

思いつく中で一番実装して価値がある機能は、配信しているデータのローカル保存機能。
私の配信している内容の場合「あんまり溜め込んでもなあ…」などと思うところがあるのでそれほど実装する事に重要性を感じてはいなかったのだが、他人が使う上で自分の配信を残すことを考えるならこの機能は結構重要な気がする。
まあ RAZIE などを併用することで録音する事はもちろんできるが、頭から欠損のないデータをネットワーク上の負荷ゼロで保存できることは地味ながら結構重要だろう。この辺は実装する事を考えていこうと思う。
録音中に容量が足りなくなった場合などを考慮して、予めドライブの空き容量不足を警告したりする機能があるといいかも知れない。

あと、これは自分でも必要と思いつつもまだ実装できていない部分なのだが、CompactFM の配信音量変更機能は若干問題がある。
もちろん機能的には正常な動作をしているが、音量変更が反映される周期が実は非常に粗い。
つまみを弄りながら「音量このぐらーい？」とかやると上手く行かないし、ミュートする場合などに不親切な部分が間違いなくあるのでここは修正したい。
あと、音量の変更をできれば滑らかになるように自動的にフェード処理をするようにしたい。動作の理想としては音量操作を行うと一定時間で音量変化していく感じで、変化幅が大きい場合は変化速度も速くなる感じで行きたい。
音量変化の実装自体は難しくないのだが、変更させようとした地点の記録をどうすればいいか迷っているのでこの辺はちょっと考え中。

それに関連して外部から音量変更出来るようにするインターフェイスを装備したいと思っている（プラグイン用の機能としてだけではなく CompactFM API としても）。
というのも、BGM を鳴らすためのツールなどをもし外部から準備する場合、PTT（Push to Talk 機能、ボタンひとつで配信中に発言用設定と音楽のみでの配信を切り替えるためのもの）を実装する場合に比較的重要になってくるのではないかと思うからだ。

現時点で BGM 配信のためのツールを外部の人が作ってくれる見込みはないのだが、API でのコントロールはできるようにしておいて損はないのでやろうと思う。
なお DirectSoundDUAL のように複数の音量調節項目を有している場合のために何番目の音量を調節するのか指定できるようにしようと思うので、音量調節に関して外部から変更する場合における制限などは特にない予定。

相変わらずやりたい事は減らない。

カレールーが入っている容器の名前

グレイビーボート、ソースポット、レトルトパウチ、どんぶり、などなど。

カレーうどんは、店によってスープを専用に作っている場合と、ただカレールーを上からかけるだけの場合と２パターンある。
後者の場合その工程の時点であまり期待は出来ないので、あまり胸は膨らませない方がいいと思う。

時間というものは

いくらあっても足りないけれど、無限に欲しいかと言われると決して欲しくない。

不思議。

USB ヘッドセットとサウンドカードでねとらじを放送する

拙作のインターネットラジオ配信ツール CompactFM は、元々は間違って Oddcast を終了してしまう私が自分のために作ったツールだった。

しかし作っている最中に「複数のデバイスから入力できるようにすれば、自分以外にも需要が出るのではないか？」と思い立ち、いつからか入力機能にプラグインシステムを搭載し、複数のデバイスから入力するための DirectSoundDUAL プラグインを作った。

このプラグインを使えば、例えば記事のタイトルにあるように USB ヘッドセット ＋ サウンドカードの音 という二つのデバイスの音をミックスさせて配信する事が出来るようになる。
だから「ただマイクが使いたくてヘッドセットを買ったのに、ラジオから声しか出せない」というしばしば起こりうる状況に対して対処できるようになっている（もちろん設定を変えてUSBヘッドセットからシステムの音声を出力するようにすれば回避できないわけではないが、なにより面倒臭いだろう）。

その他にも、例えば USB ヘッドセットを２つ繋いで放送したりする事も出来る（その場合は BGM などを流すのが手間になるが…）。
２つまでじゃなくて３つでも４つでもミックスできるようにすれば便利だと考える人も恐らく居るとは思うのだが、正直なところ個人的な用途で利用する場合は２つ以上使うケースというのは非常に稀だと思う。
そういう場合は複数のデバイスのバランスを適切に取らないと配信データが酷いことになるだろうし、使い勝手を考えるとミキサーを買ってきてツマミを手で弄ってバランス調節などした方がいいように思える（ついでにコンプとか通せばもっと良さそう）。

構想としては、もっと上を見ている部分はある。
例えば複数のデバイスからの音を入力して、リアルタイムにオーディオにエフェクトを施して声の音量を大体一定にして配信するだとか、そういう。
でも結局その辺は詳しい知識がある人じゃなければ滅多に使わないと思うし、少なくとも自分は使わないので実装にはあまり気が向かない。
（CompactFM のコアは自分で使っている限りでは今現在とても安定しているので、下手に弄らずにそのままで行きたいという考えもあったりする。）

一方で、宣伝や導入の際に敷居が高いように見えてしまっている部分もあるかも知れない。

個人的には CompactFM の初心者に対する手取り足取りのサポートをするつもりはまったくないので、導入方法に関するチュートリアルなどは同梱のヘルプ以外に用意する気はない。
サポートは非常に時間を要することで、自分のために作ったツールでそんなにサポートのために時間を割きたくない、というのが本心。
ただ、自分が使うためのツールなので機能に関しては自分が困らない程度に作りこんでいるし、自分のためにメンテナンスもそれなりにしている。
サードパーティ製ツールや、解説サイトなんかが今後充実してくれればいいのになあ、と思うところだ。

WINAMP を利用したツギハギな配信システムを脱ぎ捨てて、CompactFM を使うようになる時代がきたら、それはとても嬉しいことだ。
そのためには WINAMP で再生中の楽曲タイトルをリアルタイムに CompactFM に送りつけたりするような構造はきっと必要になるだろうし、作らないといけないのかなあ、などと思う。