Opus デコーダーを使用して、できるだけ早くオーディオ データをデコードする必要があります。
現在、私のアプリケーションは十分に高速ではありません。デコードは可能な限り高速ですが、さらに高速化する必要があります。
オーディオの約 100 セクションをデコードする必要があります。これらのセクションは連続していません (互いに関連していません)。
100 のデコードのうちの 1 つが完了するまで待つ必要がないように、マルチスレッドを使用することを考えていました。夢の中で、すべてを並行して始めることができました。これまでマルチスレッドを使用したことがありません。
したがって、私のアプローチは一般的に問題ないのか、それともどこかに考え方の誤りがあるのか を尋ねたいと思います.
ありがとうございました。
独自のスレッドを作成して管理する代わりに、スレッド プールを使用して、デコード タスクをプールに渡すことをお勧めします。プールは、システムが処理できる限り多くのスレッドにタスクを割り当てます。スレッドプールにはさまざまなタイプがありますが、特定の数のスレッドを強制的に使用するように強制したり、プールがスレッド数を増やし続けることを許可する必要がある場合など、いくつかのパラメーターを設定できます。
心に留めておくべきことの 1 つは、スレッドの数が多いからといって、それらが並列で実行されるわけではないということです。各スレッドが異なるCPUで実行されるという保証がない限り、正しい用語は並行であると思います（これにより真の並列処理が得られます）
IO がブロックされると、プール全体が停止する可能性があります。
通常はスレッドを使用できますが、ロックにはいくつかの問題があります。答えは POSIX スレッドとロックに基づいていますが、これはかなり一般的であり、アイデアを任意のプラットフォームに移植できます。ただし、ジョブでなんらかのロックが必要な場合は、次の方法が役立つ場合があります。また、スレッドの作成にはコストがかかるため、既存のスレッドを何度も使用し続けることをお勧めします (スレッド プーリングを参照)。
ロックは一般的に「リアルタイム」オーディオでは遅延が増えるため悪い考えですが、それはデコード/エンコードのリアルタイムジョブの場合は完全に問題ありません.リアルタイムのものでも、スレッドを使用することでパフォーマンスを向上させ、フレームをドロップすることはありません.知識。
オーディオの場合、セマフォは悪いアイデアです。私が試したとき、少なくとも私のシステム（POSIXセマフォ）では遅すぎますが、クロススレッドロックを考えている場合は必要になります（1つのスレッドでロックして同じスレッドでロック解除するタイプのロックではありません）。POSIXミューテックスは、セルフロックとセルフアンロックのみを許可します（同じスレッドで両方を行う必要があります）。そうしないと、プログラムは機能する可能性がありますが、未定義の動作であるため回避する必要があります。
ほとんどのロックフリーのアトミック操作では、ロックから十分な自由が得られ、一部の機能 (ロックなど) を使用できますが、パフォーマンスは向上します。
物事を高速化するための解決策としてマルチスレッドに飛び込む前に、オーバーサブスクライブとアンダーサブスクライブの概念を調べてください。
Audio の処理に IO の .long ブロッキング呼び出しが含まれる場合、マルチスレッドは価値があります。