わかりました、あらゆる種類のタイトルを試しましたが、すべて失敗しました (誰かがより良いタイトルを思いついたら、自由に編集してください:P)
次の問題があります: API を使用して、コーディングしていないハードウェアにアクセスし、その API にライブラリを追加して、API インターフェイスから継承する必要があり、API がすべてを行います。
私はそのAPI、音楽ジェネレーターライブラリを入れました。問題は、言及されたAPIがバッファーが空のときにのみ音楽ライブラリを呼び出し、ハードコードされた量のデータを要求することです(正確には1024 * 16サンプル...理由はわかりません)。
これは、音楽ライブラリが追いついていない場合でも、音楽を再生している間、音楽ジェネレータ ライブラリがすべての CPU の可能性を使用できないことを意味します。複雑なもの、バッファ アンダーラン (つまり、音楽ライブラリ関数がまだ返されていないため、サウンドカードはバッファ内の空の領域を再生します)。
ハードコードされた番号を微調整すると、いくつかの要因に応じて、ソフトウェアが一部のマシンでのみ機能し、他のマシンでは機能しなくなります...
そこで私は 2 つの解決策を思いつきました。新しいバッファ ロジックを使用して API をハックしますが、その領域については何もわかりません。
または、私が実際にロジックを考え出したもの:音楽ライブラリに独自のスレッドを持たせると、APIが音楽ライブラリを呼び出してデータを生成する代わりに、常に満たす独自の個別のバッファが作成されます。その別のバッファからサウンドカードバッファにデータを単純にコピーしてから、音楽の生成を再開します。
私の問題は、プログラミングの経験が数年あるにも関わらず、常にマルチスレッドを避けてきたことです。
質問は次のとおりです。誰かが別の解決策を見つけることができますか、またはスレッド化されたソリューションを実装する方法に関する情報を提供してくれる場所を教えてくれますか?
編集:
私はファイルを読んでいるのではなく、音楽を生成または計算しています。これは .wav または .ogg ライブラリではありません。これが、CPU 時間について言及した理由です。CPU を 100% 使用できれば、アンダーランは発生しませんが、CPU を使用できるのは、プログラムがバッファーが終わりに近づいていることを認識してから実際に終了するまでの短い時間だけです。この時間は、プログラムが音楽を計算するのにかかる時間よりも短い場合があります。