問題タブ [waveout]

私は次の状況を持っています。マシンにはFritz ISDNカードがあります。このデバイスのウェーブ アウトで特定のウェーブ ファイルを再生するプロセスがあります ( ISDN接続は起動時に確立され、永続化されます)。シナリオは簡単です。必要なときはいつでもwaveOutWrite()、以前に開いた wave デバイスでプロセスが呼び出され (もちろん、すべて問題なく初期化されます)、コールバック関数はMM_WOM_DONEmsg が再生が終了したことを知るのを待ちます。

ただし、数日後 (プロセスにもマシンにも何も変更はありません) 、波が数秒間続くにもかかわらず、MM_WOM_DONE呼び出しの直後にメッセージが届きます。waveOutWrite()ここでもエラーは報告されません。ファイルは再生されたように見えますが、長さは 0 でした (実際にはそうではありません)。また、プロセスによって呼び出されなかったと確信してwaveOutReset()います（上記のメッセージの送信もトリガーされます）。過去に奇妙な問題がいくつかありましたが、TAPIドライバーを再インストールするだけで解決しました。今回は何らかの理由でそれをもう一度実行するのは問題があり、より分析的なアプローチを試みています:)。このような動作を引き起こす可能性のある提案はありますか? 多分ISDN 回線の反対側に何かありますか?

C＃でwaveoutを使用して、より多くのwavファイル（少なくとも異なるファイル）を同時に再生しようとしました。（SoundPlayerオブジェクトは一度に1つしか再生されません。この単純な目標のために、DirectSoundおよびMediaPlayerオブジェクトやその他の高度なテクノロジを使用したくありません。）

動作するC++コードをC＃に移植し、動作します（マーシャリングの方法、ネイティブwin32 dll-sの呼び出し方法、およびアンマネージメモリの割り当てとロックの方法を調査した後）が、どういうわけかvhost.exeがクラッシュし、手がかりがありませんなぜこれを行うのですか。（例外はスローされません。標準のWindowsエラーダイアログが表示され、プログラムがクラッシュして終了します。）

誰かアイデアはありますか？

そのクラスのソースは次のとおりです。

別のフォーラムで、MIDI イベント (Note On メッセージなど) を正確に生成することについて、何人かの開発者と議論しています。人間の耳はわずかなタイミングの不正確さに非常に敏感であり、主な問題は、イベントを約 15 ミリ秒間隔で量子化する比較的低解像度のタイマーを使用していることにあると思います (これは、知覚できる不正確さを引き起こすのに十分な大きさです)。

約 10 年前、私はソフトウェア シンセサイザーと MIDI プレーヤーを組み合わせたサンプル アプリケーション (Windows 95 上の Visual Basic 5) を作成しました。基本的な前提は、各バッファーが 16 分音符のデュレーションであるリープフロッグ バッファー再生システムでした (例: 1 分あたり 120 の 4 分音符の場合、各 4 分音符は 500 ms であり、したがって各 16 分音符は 125 ms であったため、各バッファーはバッファは 5513 サンプルです)。各バッファは waveOutWrite メソッドを介して再生され、このメソッドからのコールバック関数を使用して、次のバッファをキューに入れ、MIDI メッセージを送信しました。これにより、WAV ベースのオーディオと MIDI オーディオの同期が保たれました。

私の耳には、この方法は完璧に機能しました。MIDI ノートはわずかにずれても聞こえませんでした (一方、15 ミリ秒の精度の通常のタイマーを使用して MIDI ノートを再生すると、著しくずれて聞こえます)。

理論的には、この方法は、サンプル、つまり 0.0227 ミリ秒 (1 ミリ秒あたり 44.1 サンプルがあるため) に対して正確な MIDI タイミングを生成します。バッファが終了してから waveOutWrite コールバックが通知されるまでの間にわずかな遅延があると思われるため、これがこのアプローチの真のレイテンシであるとは思えません。この遅延が実際にどれくらい大きくなるか知っている人はいますか?

コンテキスト: waveOut ハンドル (HWAVEOUT) の値を認識するコードがあります。ただし、コードはハンドルを作成しなかったため、ハンドルの作成時に waveOutOpen に渡された WAVEFORMATEX は不明です。

waveOutOpen 呼び出しに渡された WAVEFORMATEX 構造体の内容を調べたいと思います。

これが使用される場所の詳細: コードは、waveOutWrite の代わりに呼び出されるフック関数で実行されます。したがって、コードはハンドル値を認識していますが、ハンドル作成の詳細は認識していません。

人々が調べる必要がないように:
waveOutOpen の署名は次のとおりです。

waveOutWrite のシグネチャは次のとおりです。

注: waveOutOpen もフックしていますが、フックを作成する前に既に呼び出されている可能性があります。

waveOutAPIのスレッドセーフに関する情報が見つかりません。

新しいwaveOutハンドルを作成した後、次のスレッドがあります。

スレッド1：バッファ処理。これらのAPI関数を使用します。

• waveOutPrepareHeader
• waveOutWrite
• waveOutUnprepareHeader

スレッド2：Gui、コントローラースレッド。これらのAPI関数を使用します。

• waveOutPause
• waveOutRestart
• waveOutReset
• waveOutBreakLoop

これらの2つのスレッドは、同じwaveOutハンドルを同時に使用しながら実行されています。私のテストでは、機能に問題は見られませんでしたが、それが安全であるという意味ではありません。

このアーキテクチャはスレッドセーフですか？waveOut APIのスレッドセーフに関するドキュメントはありますか？waveOut APIのスレッドセーフに関するその他の提案はありますか？

ありがとう。

私は現在、音声ネットワーク チャット ソフトウェアで使用されるオーディオ エンジンを開発しています。チャンネルのキャプチャ/再生/ミキシングなど、すべて正常に動作しています。

問題は、Windows XP で使用する場合です。アプリケーションを起動した後、グローバル システム ボリュームがゼロに設定されているという情報を含むユーザー レポートを取得しています。

これは、WaveOut/DSound の競合が原因であると想定しています。

DSound がシステムの音量に影響を与えないようにするにはどうすればよいですか? 再生デバイスが初期化されます: DirectSoundCreate8(&GUID, &pAudio, NULL);

と：

pAudio->SetCooperativeLevel(parentWnd, DSSCL_PRIORITY);

現在、Vista を使用しているため、アプリケーションをデバッグできません。すべて問題ありません。

この問題で私を助けてくれることを願っています! どうもありがとう！

よろしく、アントン。

Win32 API（waveOut...関数のファミリー）をラップするC＃ライブラリを作成していますが、カプセル化を壊さずにコードのさまざまな部分間の相互作用を管理する方法がわからなくなっています。これまでのところ、次のような設定があります。

このコードで最も重要な点は、デバイスによってラップされたハンドルがデバイスの外部に表示されないことです。

AudioBlock次に、ネイティブWAVEHDR構造とオーディオサンプルデータをラップするクラスを追加します。私が直面している問題は、これから先、私が興味を持っている他のほとんどすべてのネイティブ関数（waveOut[Un]PrepareHeader、waveOutWrite）がハンドルと。の両方を必要とすることWAVEHDRです。デバイスがに触れる必要があるWAVEHDRか、ブロックがハンドルにアクセスできる必要があるようです。どちらのアプローチも、あるクラスが概念的にビジネスで知らない何かと相互作用することを意味します。

もちろん、これを回避する方法はいくつかあります。

1. ハンドルやWAVEHDRsをプライベートではなく内部にします。

2. のネストAudioBlockされたクラスを作成しDeviceます。

3. ブロックからヘッダーへのマッピングを（たとえば）維持する3番目のクラス（名前を考えることさえ躊躇します）があります(foo)Manager。これは、ブロックが与えられると、デバイスがブロックの内部に触れることなくサンプルを再生するのに役立ちます。

他にもあるかもしれません。私はそう願っています:)

これらのアプローチに対する私の異議（正しいか間違っているか）：

1. 厳密な意味では公開されていないかもしれませんが、内部メンバーを使用することは私には警官のように思えます。効果的に実装の詳細は、それらを必要としないライブラリの部分に引き続き表示されます。私は「このコードを使用または変更する人にどのインターフェースを提示したいのか」と考え続けています。

2. これはほとんど私の頭の中で機能します。ブロックをデバイスの「実装の詳細」と見なすことにより、デバイスの内部に依存できるようにすることがより受け入れられるように思われます。ブロックが実際には独立したエンティティであることを除いて。単一のデバイスに関連付けられておらず、デバイスのロジックの実装を支援するために使用されることもありません。

3. これは、私が維持したい分離のレベルに最も近くなりますが、私がよく行うように、過剰設計の領域に迷い始めています：Pまた、マッピングをそのまま維持するために、ブロックをどこかから中央に割り当てる必要があるという人工的な考えを紹介します。

それで、誰かがこのコードを（再）構築するための推奨事項を持っていますか？有効な答えには、私を説得できる限り、「あなたの異議#Xは蒸し暑い壷です」が含まれます:) ETA：たとえば、この種のことを強制しようとすることは、社会的手段（文書化、慣習）よりも優れていると思う場合技術的なもの（アクセス修飾子、アセンブリ境界）、私に知らせて、いくつかの参照を指摘してください。

私のコードには、並行して再生するウェーブアウト ハンドルがいくつかあります。

ここで、各ウェーブアウト ハンドルに異なるボリュームを設定したいと考えています。

waveOutSetVolumewin32api 関数があります: http://msdn.microsoft.com/en-us/library/ms713762%28v=vs.85%29.aspx

問題は、送信したハンドルを完全に無視し、プログラム内のすべてのウェーブアウト ハンドルのボリュームを設定することです。

ボリュームを特定のウェーブアウト ハンドルに設定するにはどうすればよいですか?

activeX フラッシュ コンポーネントが再生しているオーディオをキャプチャしようとしています。

これを行うには、flash.ocx モジュールを見つけて、waveOutWrite 関数をフックします。

これはうまくいくようですが、オーディオが同じスレッドから来て同じ出力デバイスをターゲットにしているように見えるため、内部で waveOutWrite を呼び出すさまざまな activex インスタンスを区別できません。

私の質問は、誰が waveOutWrite を呼び出しているかをどのように区別できるかということです。

モジュールのロードはCOMによって自動的に処理されるため、答えは各activexインスタンスのflash.ocxインスタンスのロードのどこかにあると思います。私が思いついたアイデアの 1 つは、別のプロセスで activex コンポーネントを作成することでした。これにより、waveOutWrite 関数が別のスレッドから呼び出されるようになることが期待されます。ただし、これはこれを達成するためのかなり複雑な方法のようです。

何か案は？