問題タブ [winmm]

生のオーディオ ストリームを録音および再生するために、WaveOut クラスと WaveIn クラスを公開する WinMM ライブラリ ラッパー ライブラリを作成しました。

すべてがうまく機能しますが、完成したバッファの処理方法に関するオペレーティング システムの仕様に従うために、バッファの準備を解除してメモリを解放するスレッドを追加しました。クラスが安定してスレッドセーフになるように、すべての同期も停止しました。

ただし、WaveOut デバイスにバッファを追加すると、オペレーティング システムが成功コードを返すというまれな問題があるようですが、直後にデバイスをリセットすると、OS はバッファを終了としてマークせず、応用。

バッファを失っているようです。したがって、問題は、デバイスに送信された個々のバッファーの数を追跡し、それらをクリーンアップするスレッドに Close() 関数を結合することをブロックしていることです。

アイデアや既知のバグはありますか?

PS: これは Vista のクアッド コアでは発生しないようですが、XP プロのデュアル コアでは発生します。

EDIT1: ソースコードをアップロードし、codeplex で適切にライセンスを取得したら、完全なソースコードを公開しても構わないと思っています。

EDIT2: ライブラリを CodePlex に投稿: http://winmm.codeplex.com/

問題の原因は次のとおりです。

NAudio を使用して複数のサウンド出力アプリケーションを作成しようとしています。8 つの USB サウンド カードがインストールされています。NAudio では 8 つすべてを使用できますが、どのデバイス インデックスがどのカードであるかを判断するためのパターンがわかりません。

カードはさまざまなハードウェアに接続されるため、使用しているカードを確認することが重要です。

WMI を使用して情報をポーリングしようとしましたが、サウンド デバイスの順序を決定する情報が見つからないようです。

更新: この問題に関する情報を含めるのを忘れていました。サウンド カードはすべて、12 ポート ハブを介して接続された USB サウンド カードです。

私は、人々がコードなどを見るための小さなオープンソースの mp3 プレーヤーを作成しています。適切なコメント、例、およびそうでないもの。

私は思っていましたが、すべての Windows インストールで winmm.dll ライブラリが見つかりますか?

私は、とりわけ、すべての入力オーディオデバイスを列挙し（を使用してSetupAPI）、オーディオデバイスごとにすべての入力オーディオラインを一覧表示する（を使用して）アプリケーションを開発していますwinmm.dll。

基本的に、この2つを関連付ける方法は、オーディオデバイスからデバイスパスを取得し、それを使用waveInMessageしてオーディオラインのデバイスパスを比較することです。

ここで、Windowsのデフォルトの[入力]オーディオライン（）でも同じことができるようにしたいと思いますWAVE_MAPPER。

問題は、waveInGetDevCapsforを使用するとWAVE_MAPPER「MicrosoftSound Mapper」が返され、 waveInMessagewithを使用するとDRV_QUERYDEVICEINTERFACE空の文字列が返されることです。

Microsoft Mapperがどのデバイスにマッピングされているかを確認する方法について何か提案はありますか？

私は winmm api を使用してオーディオを処理しています。「オーディオライン」を一意に識別するためにwaveInGetDeviceCapsandを使用しています。waveInMessageVista では、デバイスの名前がWaveInCaps構造体によって 32 文字に制限されていることを除いて、すべて正常に動作します。

これを回避するために、OS バージョンが >= Vista の場合にコア API を使用することを想定しています。IMMDeviceEnumerator.GetDeviceとを使用してIMMDeviceEnumerator.EnumAudioEndpointsオーディオ ライン情報を収集していますが、コア API の下の 1 つのデバイスが waveXx API の下の 1 つのエントリに関連していることを確認する方法がわかりません。

両方のデバイスパスを比較できると思いますが、それはデバイスパス文字列を「不透明」として扱うというMSの推奨に反します。

あなたは何と言うでしょう？

Windows（vista）でオーディオデバイス/ライン/エンドポイントに名前を付ける方法について非常に混乱しています。

• まず、コントロールパネルアプレット「サウンド」に移動します。とりわけ、USBオーディオデバイスに物理的に存在する1つの入力ラインを見つけました。アプレットの「録音デバイス」の名前は次のとおりです。
  マイク
  3-USBオーディオデバイスの動作

• waveInGetDeviceCapsから
  マイクを取得します（3-USBオーディオデバイス は閉じ括弧がないことに注意してください

• IMMDevice.IPropertyStoreから、名前を抽出できる2つのプロパティが表示されます。それらの1つは
  マイクを言い、もう1つは USBオーディオデバイス
  を言います

その「3-」はどこから来たのですか？

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

この質問はこれに関連しています。

上記の定数を使用して winmm 関数 waveInMessage を使用する必要があります。DRV_QUERYDEVICEINTERFACEmmddk.h に似たような定義 ( など) がたくさんありますが、DRV_QUERYFUNCTIONINSTANCEIDとのペアは違いDRV_QUERYFUNCTIONINSTANCEIDSIZEます。これらは、 「レガシ Windows マルチメディア アプリケーションのデバイス ロール」というタイトルの MSDN ドキュメントに記載されていますが、この例で使用されているヘッダー ファイルへの言及はありません。

このコードは、プラットフォーム呼び出しサービスを介してwinmm.dllを使用して2秒間ピアノトーンを出力するように機能します。XPでは正常に機能するようですが、Windows7rcではwaveoutopenが失敗します。

JohnKnoellerからのフィードバックに基づいて更新

System.Runtime.InteropServicesパブリッククラスAudioStreamをインポートします

エンドクラス

マネージ C# コード内からネイティブ ライブラリの関数を呼び出すことができません。これが違いを生む場合に備えて、3.5 コンパクト フレームワーク (Windows Mobile 6.x) 用に開発しています。

私はcoredll.dllのwaveIn *関数を使用しています（これらは通常のWindowsのwinmm.dllにあると思います）。これは私が思いついたものです：

ここ数日、マーシャリングについてよく読みましたが、このコードが機能しません。バッファがいっぱいのときにコールバック関数が呼び出されると (waveIn)、wavehdr に返される hdr 構造が明らかに壊れています。その時点で構造がどのように見えるかの例を次に示します。

これは明らかに、私が合格することを期待していたものではありません。ビュー内のフィールドの順序が明らかに気になります。「ローカル」ビューでレコードを表示するときに、Visual Studio .NET が実際のメモリの順序を気にするかどうかはわかりませんが、構造体で指定した順序で表示されないことは明らかです。

次に、データ ポインターがなく、bufferLength フィールドが高すぎます。興味深いことに、bytesRecorded フィールドは正確に 64000 です。bufferLength と bytesRecorded は両方とも 64000 になると思います。何がうまくいかないのか正確にはわかりません。誰かがこれについて私を助けてくれるかもしれません。私はマネージ コードのプログラミングとマーシャリングにまったく慣れていないので、私が行ったすべてのばかげたことについて、あまり厳しくしないでください。

ああ、ここで見つけた WAVEHDR の C コード定義は次のとおりです。C# 構造体定義で何か間違ったことをした可能性があると思います。

ポインター演算、キャストなどの低レベル ツールをすべて使用することに慣れている場合、マネージ コードを書き始めるのは面倒です。背中に手を縛られて泳ぎ方を学ぼうとしているようなものです. 私が試したいくつかのこと (効果なし): .NET コンパクト フレームワークは [StructLayout] の Pack = 2^x ディレクティブをサポートしていないようです。[StructLayout(LayoutKind.Explicit)] を試し、4 バイトと 8 バイトの配置を使用しました。4 バイトのアラインメントは上記のコードと同じ結果になり、8 バイトのアラインメントは状況を悪化させるだけでしたが、それは私が予想したことでした。 興味深いことに、コードを setupBuffer から setupWaveIn に移動し、クラスのコンテキストで GCHandle を宣言しませんが、setupWaveIn のローカル コンテキストでは、コールバック関数によって返される構造体が破損していないように見えます。ただし、なぜそうなのか、この知識を使用してコードを修正する方法はわかりません。やっぱりなんでもないや。私が使用していたはるかに古いコードと混同してしまいました。

マーシャリング、C# からのアンマネージ コードの呼び出しなどに関する良いリンクがあれば、本当に感謝しています。私は何を間違っていますか？期待したものが得られないのはなぜですか。