3

私は自分が持っているアイデアの概念実証を作成し始めています。この時点で、どのように開始すべきかについてのガイダンスが必要です。

しばらくの間「録音」するのではなく、マイク入力をサンプリングし、その信号をリアルタイムで処理する必要があります (Auto-Tune を考えてみてください。ただし、ライブで動作します)。

私がやっていることは、「一種の」「マイク入力から MIDI へのコンバーター」なので、非常に高速に応答する必要があります。

オンラインで少し調べたところ、どうやら進むべき道は DirectSound または WaveIn* API 関数のいずれかです。今、私が読​​んだことによると、WaveIn API を使用すると、特定のサイズのバッファーを埋めることができます。これは、記録と後処理には問題ありませんが、どうすればリアルタイム処理を行うことができるのでしょうか?

10 ミリ秒のバッファーを使用し、50 ミリ秒または 100 ミリ秒の循環配列を自分で保持し、10 ミリ秒ごとに分析をトリガーする関数を取得しますか? (最新の 100 ミリ秒の入力にアクセスでき、そのうち 10 ミリ秒のみが新しい)

ここで何か不足していますか？

また、これは DirectSound でどのように行われますか? 通常の Win32 API よりも機能が向上していますか?

4

1 に答える 1

8

DirectSound と Wave API のどちらも、最終的には、処理可能なオーディオ データで満たされたバッファーを提供します。これらのバッファのサイズはさまざまですが、現実的には、有効なリアルタイム処理のためにレイテンシを 10 ミリ秒未満に保つ必要があります。これは、バッファーに到着してから 10 ミリ秒以内にデータを処理することを意味し、オーディオ ハードウェアに到着してからバッファーに到達するまでの時間を差し引きます。これはドライバーによって異なります。このため、一度に 5 ミリ秒以下のデータを処理することをお勧めします。

この 2 つのアーキテクチャの主な違いは、DirectSound では循環バッファーを割り当て、それが DirectSound オーディオ ドライバーによって満たされるのに対し、Wave API は事前に割り当てられた WAVEHDR バッファーのキューを取得し、満たされ、アプリに返されてからリサイクルされることです。ウィンドウ メッセージやイベントなど、両方の API にさまざまな通知方法があります。ただし、処理の待ち時間を短くするには、専用のストリーミング スレッドを維持し、新しいデータが到着するまで待つことをお勧めします。

さまざまな理由から、新しい開発には Wave API よりも DirectSound をお勧めします。より低いレイテンシーを達成するのは確かに簡単です。

どちらの方法でキャプチャを行う場合でも、データを取得したら、それを処理アルゴリズムに渡し、次のバッファの準備が整うまで待ちます。到着するよりも速くデータを処理できる限り、(疑似) リアルタイム分析を行うことができます。

より適切な代替 API もあります。ASIO、 Kernel Streaming (XP のみ - 私は気にしません)、および Vista の新機能であるCore Audio APIをご覧ください。

于 2008-11-03T13:23:36.827 に答える