私は最近まさにこの問題を経験しており、とにかく意図していたので、レンダー コールバックでオーディオを手動でミキシング/サミングするときに使用できる 3 つのオプションについて詳細な投稿を書きました。
iOS でクリッピングを行わずにオーディオをミキシングする: リミッターとその他のテクニック
基本的に、最初の方法は、参照したブログ投稿で概説されています。ただし、A Tasty Pixel の投稿で述べられているように、この「平均化」手法では高調波歪みが発生します。ただし、ソースがフル トラックやノイズ ベースのパーカッション (スネア ドラムなど) の場合など、特定のアプリケーションでは目立たないようです。A Tasty Pixel によると、プロ仕様のオーディオ ツールであるLoopy appは、この手法をうまく使用しています。
2 番目のオプションは、自然なサウンドや高いポリフォニーを使用している場合に適していると思われますが、オーディオ データを 0 < A < 1 で事前に乗算することにより、オーディオの音量を下げるだけです。私のブログ投稿で概説した理由により、OpenAL は割り当てたソースの数に基づいてこれと同様のことを行います。倍率は、思ったほど低くする必要はありません。私のアプリ、Sound Wand、フル スケールに正規化されたサンプルと 20 の最大ポリフォニーがあり、約 1/3 (1/20 ではない) のプリスケール値のみを使用します。利点は、楽器のダイナミックレンジが非常に優れていることです。つまり、柔らかい音は静かで、硬い音、またはそれらの多くが一緒になるとはるかに大きくなります。これは、高品質の楽器の特徴の 1 つと見なされることがよくあります。欠点は、iPhone/iPad の内蔵スピーカーでは少し静かで、安価な外部アンプにはダイナミック レンジが大きすぎることです。
3 番目のオプションは確かにブリックウォール リミッターですが、単純なものは何もありません。通常のブリックウォール リミッターでは、クリッピングは防止されません。先読みブリックウォール リミッターが必要ですが、これらのコードはすぐには利用できません。先読みが必要な理由は、クリッピングが最初に発生するポイントまで、リミッターが音量をスムーズに下げるのに時間がかかるためです。ボリュームを下げて 1.0 に戻すことは、クリッピングとまったく同じことなので、波形がクリップし始めたときに「すぐにボリュームを下げる」だけでは十分ではありません。その結果、非先読みリミッターはクリップの半分しか削除しません (それはリリース時間のためだけです)。

(「先読み」なしのブリックウォール制限は遅すぎて、クリップの半分しか防止できません)
先読みリミッタにも欠点があります。クリッピングよりもはるかに少ないですが、独自の高調波歪みが発生します。さらに悪いことに、ユーザーのアクションと音声結果の間の時間であるレイテンシーが、先読み時間によって増加します。これは、応答性の低いアプリを意味します。ご想像のとおり、先読みが長いほど、結果がより透明になる (歪みが少ない) ことを意味するため、トレードオフがあります。私はまだこれが実行可能な方法であると信じており、投稿の最後で少し概説しています.
remoteIO での手動ミキシングに対する AU ミキサーの使用に関する最後の注意事項: チャネルがオーディオ「トラック」のようなもので、通常のボリューム/パンをユーザーが制御したい場合、一般的に AU を使用する傾向があります。または、おそらくバックグラウンド/フォアグラウンド/などのいくつかのチャネルを持つゲームがある場合。キーボード上の音符のように多くのサウンドがある場合、またはサミングを特注で制御したい場合 (たとえば、さまざまなパンの法則、サウンドのオン/オフに関する特別なルールなど) は、手動で行ったほうがよい場合があります。いくつかのオーディオ トラックを合計するだけの場合は、実際にはどちらのオプションでもうまくいきません。上記のオプション 2 を使用する場合、 Accelerate Framework の vDSP 機能に手を入れてから手動で実行すると、実際には数行のコードしか必要ありません。