1

私は最近、入力されたマイク データに対してリアルタイムのスライディング FFT 分析を実行する必要があるプロジェクトを取り上げました。これを行うために選んだ環境は、OpenGL と Cinder で、C++ を使用しています。

オーディオ プログラミングは初めての経験で、少し混乱しています。

これは、OpenGL アプリケーションで達成しようとしているものです。

ここに画像の説明を入力

したがって、すべてのフレームには、受信データの一部があります。for ループ (したがって複数のパス) では、現在のデータのウィンドウが消費され、FFT 分析が実行されます。forループの次の反復では、ウィンドウはデータの最後に到達するまで、データなどを通じて「ホップサイズ」を進めます。

現在、このプロセスは連続している必要があります。しかし、上の図でわかるように、現在のアプリ フレームが終了し、次のフレームのデータが入ってくるとすぐに、前のフレームを離れた場所を取得できません (データが既になくなっているため)。青い領域が 2 つのフレームの間にある図で確認できます。

今、あなたは言うかもしれませんが、これが決して起こらないようにウィンドウサイズ/ホップサイズを選んでください。

C++11 向けのこの種の処理に関する提案も大歓迎です!

ありがとう!

4

2 に答える 2

1

あなたのシナリオを 100% 理解しているかどうかはわかりませんが、循環バッファーを使用することをお勧めします。「標準」の循環バッファはありませんが、 Boost にはあります。

ただし、2 つのスレッドで処理を行う場合はロックが必要です。たとえば、1 つのスレッドはオーディオ入力を待機し、バッファ ロックを取得して、オーディオ バッファから循環バッファにコピーします。2 番目のスレッドは定期的にバッファ ロックを取得し、次のk要素を読み取ります (少なくともkバッファ内に利用可能な要素がある場合)。

バッファーのサイズを適切に調整し、循環バッファーでの損失を回避するために、常に着信速度よりも速くデータを処理するようにする必要があります...

バッファがロックフリーであると言及する理由と、それが要件であるかどうかがわからない場合は、概念的にはより単純に見えるため、最初にロック付きの循環バッファを試し、必要な場合にのみロックフリーにします。この場合、より複雑になる可能性があります(ただし、「プロデューサー-コンシューマー」ロックフリーキューが機能する可能性があります)...

HTH。

于 2015-02-09T05:33:19.077 に答える