問題タブ [directsound]

Directsound と Windows ミキサーについていくつか質問があります。私の目標は、すべてのマイクを列挙し、それぞれの入力音量を変更できるようにすることです。私は解決策から遠く離れていないと思いますが、コードの何が問題なのかわかりません。これが私がやったことです: - すべての入力デバイスを列挙し、それぞれの GUID を取得します - トピックで見つかったメソッドを使用して、このメソッドを使用して directsound GUID に対応するミキサー ID を取得します (ただし、動作します) - 次に、ミキサーのコントロールに対応する ID を取得します - 次に、ボリュームを変更できます

コードは次のとおりです: vs2008 プロジェクト

テストするために、2 つのマイク USB + ライン入力マイクを接続し、どのスライダーが動いているかを視覚的に確認しました。しかし、残念ながらそれは良いものではありません... これは、Windows XP で開いたすべてのミキサーのスクリーンショット (img177.imageshack.us/img177/5189/mixers.jpg) です。

私が間違っていることを知っていますか？最も簡単な解決策はありますか？

おまけの質問: Directsound を使用して、マイクがライン入力に接続されているかどうかを知る方法があるかどうか知っていますか? マイクが接続されていなくても、ライン入力は常に接続されていると検出されるためです。

単純なDirectSoundアプリを作成しようとしていますが、.netドキュメントがないのでイライラします。

あるデバイスからオーディオをキャプチャして、別のデバイスで再生したいのですが。（オーディオリピーターのように）キャプチャ部分はありますが、キャプチャバッファーをセカンダリバッファーに送信する方法がわかりません。

誰かがそこに.netの例を知っていますか？

これを尋ねる理由は、waveInOpen を使用して開いたような特定の winmm オーディオ デバイスを directSound デバイスと関連付けたいからです。

私が決心するのを手伝ってください。

1. アプリケーションの開始時に割り当て、終了時に解放します。
2. ストリーミングの開始時に割り当て、ストリーミングが停止するとすぐに解放します。

どれ？なんで？

重要な場合: Ekiga のような音声通信アプリケーションです。DSSCL_NORMAL を使用してバッファーを割り当てています (テストした限り、8 ビット 22KHz の制限は誤りです)。

そうです、Delphi voip アプリに DirectSound を実装する作業を行っています (このアプリでは、ネットワーク接続を介して複数のユーザーが無線を使用できます)。データは UDP ブロードキャスト経由で入ってきます。現在のように、生データ レベルに落とし込み、複数のソースからのオーディオ ミキシングを自分たちで行い、これらすべてを再生するために使用される中央コンポーネントを持っています。

アプリ自体は Delphi 5 アプリで、Delphi 2010 への移植を任されています。このオーディオ再生部分に到達したら、この古いコードを取り除き、directsound に置き換えることが最善であるという結論に達しました。

したがって、アイデアは、ラジオごとに 1 つの SecondaryBuffer を持ち (特定のラジオごとに作成するコンポーネントのセットに基づいて、ラジオ接続ごとに 1 つの「パネル」をそれぞれ持っています)、これらが取得するたびに、それぞれの SecondaryBuffer にデータを追加できるようにすることです。データがなくなった場合、一時停止してバッファ内の 0.5 秒分のオーディオ データを埋めるだけです。

今、私はテストアプリケーションのバッファにデータを追加している部分で立ち往生しています.これを適切に動作させようとしてから、コンポーネントを書き始めて、それを必要な方法で利用します.

Delphi 用に移植された DirectX ヘッダーを使用しています ( http://www.clootie.ru/delphi/download_dx92.html )

これらのヘッダーのポイントは、通常の DirectSound インターフェイスを Delphi に移植することです。そのため、DirectSound を使用する Delphi 以外のプログラマーも、私の問題の原因を知っている可能性があります。

私の SecondaryBuffer (IDirectSoundBuffer) は次のように作成されました。

PrimaryBuffer を定義した部分 (ループ フラグを使用するように設定されており、MSDN が言うように正確に作成されています) と DSInterface を省略しましたが、IDirectSoundInterface はご想像の通りです。

現在、音声メッセージ (7 年以上動作することが確認されている他のコンポーネントによって検出、デコード、および適切な音声形式に変換されます) を受け取るたびに、次のことを行います。

AudioData には、メッセージ内のデータが含まれています。メッセージには、常に512 バイトのオーディオ データが含まれます。Memo1.Lines.Add 行を追加して、デバッグ出力を取得できるようにしました (directsound がプライマリ バッファーの内容を再生し続けるため、ブレークポイントを使用してもうまくいかないため)

ここで、ループ フラグを使用して DSCurrentBuffer を再生し (MSDN のドキュメントによると、ストリーミング バッファにするのに十分です)、このコードが必要に応じて機能するようにすると、メモの出力テキストは、私がバッファの最後まで書き込むことができます...しかし、ラップしません。

SecondPart は常に nil です。バッファの先頭に戻ることはありません。つまり、同じ数秒間のオーディオ データが何度も再生されます。

はい、私はこのようなことを行うことができるコンポーネントをネットで探しましたが、信頼できる唯一の方法はこのように自分で行うことであると結論付けました.

そして、はい、このアプリが再生するオーディオ データは途切れ途切れです。write-to-buffer コードが適切にラップされるようになるまで、0.5 秒のバッファリング コードの作成を延期します :/

私は人々があなた自身の書き込みカーソルを追跡することを提案していると読んでいますが、私が読んだことから、ロックとロック解除はその必要性を回避するのに役立つはずです. また、前後に交互に使用する 2 つのバッファー (または、本質的に同じものであり、記述が少し複雑な分割バッファー) を使用する必要は避けたいと思います。

どんな助けでも大歓迎です！

Wave がデバッグ中に再生されません。CTRL+F5 を押すと、素敵な WAV が得られ、コンソールはファイル カーソル位置 ( buf.PlayPosition) を書き出し、サウンドが終了するとメソッドは終了します。デバッグ中 (F5 キーを押したとき) はオーディオ出力はありませんが、コンソール ウィンドウでファイル カーソルの位置が増加し、メソッドは例外なく終了します。

何か案は？

さらに別のDirectSoundの質問に戻ります。これは、DirectSoundバッファの使用方法に関するものです。

アプリケーションの他の部分によって生のwavデータにデコードされるオーディオデータを含むパケットが約30ms間隔でネットワーク経由で着信しています。

Indataイベントがこれらの他のコードによってトリガーされると、基本的に、オーディオデータをパラメーターとして使用するプロシージャにドロップされます。

DSCurrentBufferは次のように初期化されました。

このデータを次のようにセカンダリバッファに書き込みます。

ここでは、入力データは音声データに変換されますが、質問自体には関係ありません。

上記は、OnAudioDataイベントで実行するコードです（プロトコルで送信されたメッセージをデコードする独自のコンポーネントによって定義されます）。基本的に、コードは、オーディオデータを含むUDPメッセージを取得するたびに実行されます。

バッファに書き込んだ後、バッファに十分なデータが入ったら再生を開始するために次のことを行います。ちなみに、BufferSizeは現時点で1秒に相当するように設定されています。

これまでのところ、オーディオの再生は少し途切れがちですが、これまでのところ良好です。残念ながら、このコードでは十分ではありません。

また、再生を停止し、データが不足したときにバッファが再びいっぱいになるのを待つ必要があります。これは私が問題にぶつかっているところです。

基本的に、オーディオの再生が最後にバッファに書き込んだ時点に到達したことを確認し、書き込みが終了したときに停止できるようにする必要があります。そうしないと、もちろん、受信しているオーディオデータの遅延によってオーディオが台無しになります。残念ながら、バッファへの書き込みを停止することはできません。バッファを再生し続けると、1秒前に残った古いデータが再生されるだけです（循環している場合など）。したがって、PlayCursorPositionかどうかを知る必要があります。バッファ書き込みコードで追跡しているLastWrittenByte値に達しました。

DirectSound Notificationsは私にとってこれを行うことができるように見えましたが、データを書き込むたびにバッファを停止してから新たに開始すると（SetNotificationPositions（）ではバッファを停止する必要があります）、再生自体に顕著な影響があるため、オーディオそれは以前よりもさらに壊れた音を再生します。

通知を受け取るために、これを記述コードの最後に追加しました。バッファにデータを書き込むたびに新しい通知を設定することは、おそらくうまく機能しないだろうと思っていました...しかし、ちょっと、試してみても害はないと思いました：

NotificationThreadは、WaitForSingleObjectを実行するスレッドです。CreateEventは、新しいイベントハンドルを作成し、WaitForSingleObjectが前のイベントハンドルの代わりにそれを待機し始めるようにします。ReachedLastWrittenByteは、私のアプリケーションで定義されているプロシージャです。スレッドはクリティカルセクションを開始し、通知がトリガーされたときにそれを呼び出します。（もちろん、WaitForSingleObjectは20ミリ秒のタイムアウトで呼び出されるため、CreateEventが呼び出されるたびにハンドルを更新できます。）

ReachedLastWrittenByte（）は次のことを行います。

通知がトリガーされ、使用しているセカンダリバッファで停止を呼び出すと、オーディオはプライマリバッファに残っているデータのように見えるものをループし続けます...

それでも、通知は適切にトリガーされません。これらのオーディオメッセージを送信している他のアプリケーションからのオーディオデータのブロードキャストを停止すると、バッファ内の残りの部分をループし続けます。つまり、基本的には、設定した最新の通知（lastwrittenbyte）を超えています。再生中は、ときどき停止し、バッファがいっぱいになってから再生を開始します...バッファがいっぱいになった後、入ってくるデータを再生するために、バッファリングしたばかりのデータの0.5秒をスキップします（つまり、バッファがいっぱいになりますが、新しいデータの入力を開始する前にその内容を再生する必要はないようです。ええ、私にもわかりません。）

ここで何が欠けているように見えますか？DirectSound Notificatiosnを使用して、最後に書き込まれたバイトがいつ再生されたかを確認するというアイデアは、無駄な努力ですか？ストリーミングバッファを使用してこの種のバッファリングを行う方法があると思います。

サンプルサイズを変更したり、再サンプリングしたりせずに、多くのオーディオをソース形式から PCM にトランスコードしたいと考えています。Windows Media Player でファイルを再生でき、従来の ACM コーデックを使用していない場合は、DirectSound を使用している必要があります (これは Windows XP および Windows Server 2k3 での結果です)。C# から DirectSound にアクセスすることは可能ですか? Web を検索してみましたが、すべての例は私が興味のない再生に関するものでした。

まず第一に、私はただの趣味なので、これがばかげた質問であったり、あまりにも素朴すぎたりしたら申し訳ありません. (高価なライブラリを買えないということでもあります)

これが状況です: 私は C#.NET で簡単なボイス チャット アプリケーションを構築しています (Ventrilo や TeamSpeak のようなものですが、約 15 人または 20 人のみで、100Mbps LAN で実行されます)。サーバー (各クライアントの生成スレッド) と、接続に UDP を使用し、サウンドのキャプチャと再生に DirectSound を使用するクライアント アプリケーションがあります。「1 対 1」の電話をかけることはできますが、最も重要なことの 1 つがわかりません。

会話に 2 人以上が参加するにはどうすればよいですか?

オーディオを処理するための.Netアプリケーションを作成し、ClickOnce配置を使用して配布したいと思います。生のオーディオパイプラインにアクセスする必要があります。どのオーディオライブラリを使用する必要がありますか？DirectSoundのマネージドライブラリは行き止まりだと聞きました。クライアントのマシンにインストールする必要があるのは可能な限り少なくします。ClickOnceプロセス以外のものは機能しません。

NAudioの可能性はありますが、別のドライバーをインストールする可能性はありませんか？SlimDXもあります。

残念ですが、マネージドDirectXライブラリはうまく機能しているようです。私が読んだところによると、DirectXはClickOnceのインストールに含めることができます。