2

要約すると、私の質問は次のとおりです。15 の非可逆圧縮オーディオ トラックをオンザフライで同時に 50 ミリ秒未満の遅延で途切れることなくデコードして再生することは可能ですか?

バックグラウンド

私が作成しているゲーム用にプレーン C でサウンド ライブラリを作成しています。50 ミリ秒未満のレイテンシで、最大 15 のオーディオ トラックを一度に再生したいと考えています。

現時点では、このライブラリは生の PCM ファイル (48000Hz パックの 16 ビット サンプル) を再生でき、15 のサウンドを一度に 45 ミリ秒のレイテンシで途切れることなく最小限の CPU 使用率で簡単に再生できます。これは私の比較的古い Intel Q9300 + SSD マシンにあります。

生のオーディオ ファイルは巨大なので、opusfile ( https://mf4.xiph.org/jenkins/view/opus/job/opusfile-unix/ws/doc/html/index ) を使用して OPUS ファイルの再生をサポートするようにライブラリを拡張しました。 .html )。オーディオ ファイルが 200MB 以上を消費することなく、一度に 15 のサウンドを再生できることを期待していました。私がどれほど間違っていたか - 吃音やその他のバッファー アンダーランの症状が聞こえる前に、一度に 3 つまたは 4 つの OPUS トラックしか再生できませんでした。CPU 使用率も生の PCM 再生と比較して大幅に増加しました。

また、vorbisfile ( http://www.xiph.org/vorbis/doc/vorbisfile/ ) を使用して VORBIS サポートを含めてみました。オンザフライで VORBIS をデコードしても、それほど CPU 負荷がかからないのではないかと考えました。VORBIS は OPUS より少し優れています - スタッターが聞こえるようになる前に一度に 5 つまたは 6 つのサウンドを再生できます (VORBIS の方がデコードが簡単だと思います) - しかし、生の PCM ファイルを再生するほどではありません。

低レベルの libvorbis/libopus API を掘り下げて、他のオーディオ圧縮形式を調査する前に、50 ミリ秒未満のレイテンシで途切れることなく、オンザフライで同時に 15 の非可逆圧縮オーディオ トラックをデコードして再生することは実際に実行可能ですか?ミディアムからローエンドのデスクトップコンピューターでは？

それが役立つ場合、私のサウンド ライブラリは現在、約 15 ミリ秒ごとに関数を呼び出します。これは、基本的に次のことを行います (わかりやすくするために、エラー処理と後処理は省略されています)。

void onBufferUpdateNeeded(int numSounds, struct Sound *sounds,
    uint16_t *bufferToUpdate, int numSamplesNeeded, uint16_t *tmpBuffer) {
    int i, j;
    memset(bufferToUpdate, 0, numSamplesNeeded * sizeof(uint16_t));
    for (i = 0; i < numSounds; ++i) {
        /* Seek to the specified sample number in the already-opened
        file handle. The implementation of this depends on the file
        type (vorbis, opus, raw PCM). */
        seekToSample(sounds[i].fileHandle, sounds[i].currentSample);

        /* Read numSamplesNeeded samples from the file handle into
        tmpBuffer. */
        readSamples(tmpBuffer, sounds[i].fileHandle, numSamplesNeeded);

        /* Add the samples into the buffer. */
        for (j = 0; j < numSamplesNeeded; ++j) {
            bufferToUpdate[j] += tmpBuffer[j];
        }
    }
}

助けてくれてありがとう！

4

1 に答える 1

0

あなた自身の質問に対する答えはすでにわかっているようですね: NO. 通常、このような質問 (特にパフォーマンス関連のクエリ) に対する唯一のアドバイスは、試してみて、可能かどうかを調べることです。しかし、あなたはすでにそのデータを収集しています。

確かに、知覚的/非可逆オーディオ コーデックは、デコードに計算負荷が高くなる傾向があります。raw PCM のストレージ オーバーヘッドを回避したいようです。その場合、アプリケーション用に十分なメモリが予約されていると安全に想定できる場合は、オーディオ ストリームを事前にデコードするか、キャッシュ メカニズムを使用してメモリの制約に対処することができます。おそらく、これは別のスレッドにオフロードできます（質問で言及されているQ9300 CPUはデュアルコアであるため）。

それ以外の場合は、計算要件がより低いコンプレッサーを探す必要があります。Vorbis や Opus と同じ組織が後援するFLACに興味があるかもしれません。無損失であるため、非可逆アルゴリズムほどには圧縮されませんが、デコードははるかに高速になるはずです。

それでも問題が解決しない場合は、基準を満たすものが見つかるまで、この 150 までのオーディオ コーデックの大きなリストを参照してください。クライアント ソフトウェアを制御するため、多くの選択肢があります (たとえば、Web ブラウザーへのストリーミングとは異なります)。

于 2015-08-14T21:11:55.233 に答える