背景紹介
WebRTC は現在、リアルタイム オーディオおよびビデオの分野で最も人気のあるオープン ソース フレームワークです。Google が 2010 年に GIPS エンジンを買収した後、それは Chrome システムに組み込まれ、「WebRTC」と名付けられてオープンソース化されました。WebRTC は主要なブラウザ メーカーによってサポートされており、モバイル インターネット アプリケーションにおけるリアルタイム オーディオとビデオの普及を促進する W3C 標準に組み込まれています。2021 年 1 月、2 つの主要な標準設定団体である W3C と IETF は、WebRTC が公式標準になったと発表しました。ユーザーは、ネットワーク上でのリアルタイムのオーディオおよびビデオ通信をサポートするために、追加のコンポーネントや個別のアプリケーションをダウンロードする必要はありません。WebRTC はフリーかつオープンソースの特徴を持っていますが、巨大で複雑で学習の敷居が高く、サーバー ソリューションの設計と導入が不足しているため、WebRTC をベースにした商用ソリューションを開発する余地が残されています。サードパーティの RTC PaaS ベンダーは、そのスケール効果と技術的利点により、開発者の第一の選択肢となり、リアルタイム オーディオおよびビデオ業界を開発の高速レーンに押し上げています。
この記事では、webrtc のオーディオ エンジン アーキテクチャに焦点を当て、その背後にある音質に影響を与える重要な技術的ポイントを分析し、業界の主流 RTC メーカーのさまざまなビジネス シナリオの背後にある差別化された技術ソリューションの下での選択の考慮事項を紹介し、明らかにします。フルリンクシナリオ での最高の音質改善ソリューション。
1. webrtc オーディオ アーキテクチャの概要
RTC 全体のオーディオ アーキテクチャを上の図に示します。
アップリンク:オーディオ信号がデバイスによって収集されてコールバックされた後、ソフトウェア 3A (音響エコー キャンセル (AEC)、自動ノイズ抑制 (ANS)、自動ゲイン制御 (AGC)) によって処理され、次に、オーディオ エンコーダ。RTP パッケージ化を実行して SFU に送信します。送信側は取得スレッドによって駆動されます。取得デバイスが開始された後、10 ミリ秒ごとにオーディオ データをコールバックします。データは、取得スレッドをブロックせずに時間内に削除する必要がありますプッシュ モードです。通常、取得スレッドとソフトウェア 3A は取得スレッドで処理され、オーディオ エンコード リンクへの処理は非同期スレッドです。
ダウンリンク:受信側では、ネットワーク パケットの損失、遅延、ジッター、順序外れなどの要因により、オーディオ RTP パケットを受信した後、分析と並べ替えのために neteq に入れられます。デコーダー (Decoder) はデコードを実行するために呼び出されます。デコードされた PCM データは、neteq のさまざまな判断戦略に従って、パケット損失補償 (PLC) や加速再生などの後処理を実行し、さまざまなチャネルの処理されたオーディオ データ ストリームを実行します。ミキサー (Mixer) によってミキシングされます。 レンダーに適した形式で再生するために、ミキシング後、レンダーに送信する前に、エコーを除去し、エコーを除去するためのリモート基準信号としてソフトウェア 3A AEC モジュールにも送信されます。ピアエンドユーザーは自分の声を聞くことができません。取得スレッドとは異なり、ダウンリンクはレンダリング (再生) スレッドによって駆動されます。レンダリング スレッドの開始後、10 ミリ秒のフレームごとのタイミング コールバックが、プル モードによって駆動される再生バッファからのデータを要求します。
2. RTC の音質に影響を与える要因
1 のオーディオ アーキテクチャの説明によると、rtc のエンドツーエンドの音質体験に影響を与えるフルリンク要素は、オーディオ機器、オーディオ 3A、オーディオ エンコーダ、Neteq の 4 つの側面に集中しています。
2.1 オーディオ機器
音質に影響を与えるのはオーディオ機器ですが、両端のオーディオ機器の特性や性能は異なりますので、両端のオーディオ機器の違いを深く理解することが音質向上の第一歩であり、音質向上の第一歩となります。
2.1.1 Android端末
オーディオ ドライバー: Android は、さまざまなオーディオ キャプチャおよび再生ドライバーを提供します。現在主流のオーディオ キャプチャおよび再生ドライバーは、Java ベースの AudioRecord および AudioTrack モード、および C++ ベースの Opensles ドライバーです。さらに、Google は、Android O バージョンで新しい Android C API、AAudio を導入しました。関連情報: https://開発者 .android.com/ndk/guides/audio/aaudio/aaudio、この API は低遅延を必要とする高性能オーディオ アプリケーション向けに設計されているという公式声明。
Java: オーディオレコード/オーディオトラック
Opensles: C++ ——— (低遅延、業界の主流)
AAudio————問題点が多く改善の余地あり
オーディオパラメータ:
オーディオモード:
オーディオソース：
StreamType: 音量バーに影響します。
RTC ハードウェアおよびソフトウェア 3A パラメータ設定: AudioMode/AudioSource/StreamType
ハードウェア 3A: audioMode = MODE_IN_COMMUNICATION audioSource = VOICE_COMMUNICATION、streamType = STREAM_VOICE_CALL;
软件3A: audioMode = MODE_NORMAL; オーディオソース = MIC; ストリームタイプ = STREAM_MUSIC;
ハードウェア 3A モードとソフトウェア 3A モードの違い:
業界の一般的な慣行: Android の断片化により、携帯電話メーカーごとにオーディオ ドライバーのサポート機能が異なり、互換性もかなり異なります。最も一般的な Java モードと Opensles モードにも適応の問題があるため、オンAndroid 側では、RTC メーカーは通常、安定性と使いやすさの問題を解決するために、さまざまな Android モデルと組み合わせた上記のパラメーターに基づいた構成を提供します。以下に示すように、これは典型的な構成配布パラメーターです。
{"audioMode":3,"audioSampleRate":48000,"audioSource":7,"query":"oneplus/default ","useHardwareAEC":true,"useJavaAudioClass":true}
現在、RTC分野ではopenslesが広く使われていますが、その理由の一つとして、アーキテクチャ的にはADM(AudioDeviceModule)がC++層の一元管理であり、C++層のデータコールバックが削減に都合がよいためです。 java->jni->c++ からの時間のかかるデータ コールバック。
収集の音質に対するチャネルの影響: 一般に、バイノーラル収集のスペクトル成分は、モノラル収集のスペクトル成分よりも豊富です。
Android ハードウェア 3A、ネイティブ Android はハードウェア AEC と ANS のオン/オフをサポートしていますが、現在の国内 Android 携帯電話メーカーのカスタム Rom 修正により、ほとんどの Android 携帯電話メーカーはハードウェア 3A でハードウェア AEC と ANS を有効にすることを余儀なくされています。本当にオフにすることはできません。
https://developer.android.com/reference/android/media/audiofx/AcousticEchoCanceler
https://developer.android.com/reference/android/media/audiofx/NoiseSuppressor
Androidオーディオキット
ファーウェイオーディオキット:
https://developer.huawei.com/consumer/cn/codelab/HMSAudioKit/#0；https://developer.huawei.com/consumer/cn/doc/development/Media-Guides/introduction_services-0000001053333356；
統合の利点: 工場 A の一部の携帯電話収集信号における帯域幅損失の問題を解決できます。
制限要因:
紅蒙システム
キリンチップ
再生スレッドはキャプチャ スレッドの前に開始されます
帯域幅の問題に加えて、Andorid デバイスのサンプリング レートもデバイスによって大きく異なります。通常、44100 または 48000 Hz のサンプリング レートがより互換性があります。デバイスによって、これら 2 つのサンプリング レートは異なる場合があります。サポート パフォーマンスたとえば、ハードウェア 3A のエコー キャンセル効果が良くない場合や、コレクション コールバック データが不安定である場合など、サンプリング レートに応じてモデルを適応させる必要もあります。
2.1.2 IOS端末
音量バー:
iOS側も通話音量バーとメディア音量バーに分かれていますが、iOSシステムのUI表示は区別されず、UIアイコン表示は同じです。見分け方は下図の通りです。 . 0 に調整でき、メディア音量バー、音量バーは 0 に調整できます。
ソフトウェアとハードウェア 3A:
IOS システムでは、同じ現象が Android システムでも同様です。
RTC シナリオでは、IOS システム ソフトウェアとハードウェア 3A パラメータの配置は次のとおりです。
ハードウェア 3A: kAudioUnitSubType_VoiceProcessingIO + AVAudioSessionModeVoiceChat
软件3A: kAudioUnitSubType_RemoteIO + AVAudioSessionModeDefault
以下は、iOS 関連のシステム インターフェイスの説明です。
WebRTC は iOS プラットフォームで AudioUnit 取得を使用し、関連するコードは次のとおりです。
Apple の API 説明によると、iOS は 3 つの I/O ユニットを提供しており、そのうちリモート I/O ユニットが最もよく使用されます。入出力オーディオ ハードウェアに接続し、受信および送信サンプル値への低遅延アクセスを提供し、ハードウェア オーディオ フォーマットとアプリケーション オーディオ フォーマット間のフォーマット変換を提供します。音声処理 I/O ユニットは、リモート I/O ユニットを拡張したもので、ボイスチャットにおけるエコーキャンセル機能を追加し、自動ゲイン補正、音質調整、ミュートなどの機能も提供します。汎用出力ユニットはオーディオ ハードウェアに接続せず、処理チェーンの出力をアプリケーションに送信するメカニズムを提供します。通常、オフラインのオーディオ処理に使用されます。
2.1.3 Windows側
Windows 側には、通常、dsound、CoreAudio、Wav の 3 セットのオーディオ デバイス ドライバーがあります。
Dsound - 最高の互換性、より多くのデスクトップ使用
CoreAudio - 互換性が 2 番目
Wav - ほとんど使用されない
現在、多くの Windows デバイスには、オーディオ拡張機能を提供するために画面上部にマイク アレイが組み込まれており、その開き方は次の図に示すとおりです。この機能は、デフォルトで画面の前の領域を収音領域として設定します。マイク アレイ技術により、収音領域内の話者の音声を効果的に強調し、収音領域外の「ノイズ」を「分離」できます。主な欠点は、この機能を開くと、8kスペクトルのみがサポートされ、各メーカーの強化アルゴリズムが異なり、効果も不均一であることです。したがって、ソフトウェアには、高音質を確保するためにハードウェアのオーディオ拡張機能をバイパスする機能が必要です。
<オーディオ設定の拡張機能スイッチ>
<オーディオエンハンスメントをオンにした後の周波数スペクトルの損失>
音量の点では、PC 側デバイスはアナログ ゲイン調整をサポートしており、アレイを備えたほとんどの Windows デバイスには追加のマイク拡張機能があります (以下を参照)。ソフトウェア アルゴリズム レベル (3A の AGC) は、オーディオ収集ボリュームの安定性を確保して収集ノイズ フロア レベルを制御するために、それらを適応的に調整する機能を備えている必要があります。初期値の設定やアダプティブ調整が適切でないと、音量が小さい、プチプチ音などの不具合が発生し、エコーキャンセリングやノイズリダクションの効果に重大な影響を及ぼし、使用感に影響を与える恐れがあります。
<アナログゲインとマイクブースト>
2.1.4 Mac端末
Mac 側はあまり使用されていないため、ここでは詳しく紹介しません。
Mac 側は、Windows 側と同様のアナログボリュームの動的調整をサポートしています。
2.1.5 オーディオ機器の一般的な問題と解決策
ハードウェアのメーカーが異なるため、各エンドの音声収集ソリューションにはばらつきがあるため、収集された音声の品質は、3A アルゴリズムによって得られる制作素材の使いやすさに直接影響し、エンド ユーザーが受信する音声信号の品質も決まります。上限です。実際の作業で遭遇するオーディオの問題によると、機器の入手によって引き起こされる問題は、基本的に次のカテゴリに要約できます。
いくつかの例を挙げると、次のようになります。
(1) 異常収集：
取得異常は主に「ファジー」スペクトルに反映されており、意味論を理解できなくなり、通常のコミュニケーションに影響を与える可能性があります。スペクトログラムは以下の通りです。
さらに、取得が異常になると、下図に示すように、マイクで集音した後のブロードキャスト信号も異常に見えるため、重大な非線形歪みが発生し、エコーキャンセル効果に影響を与えます。
(2) アクイジションジッタ
共通しているのは、データの収集と消失であり、聴覚的には多くの高周波ノイズが聞こえます（下の写真は、上の写真のノイズを拡大した後の部分写真です）。これは、データに深刻な影響を与えます。 AEC アルゴリズムにおける遅延推定精度と遠近端の非線形性原因と結果の問題、深刻なものはエコー漏れにつながります。
(3) プチプチ音や音量に若干の不具合がある場合
取得ポッピングは主に PC で発生しますが、PC 側のデバイスでも回避すべき問題であり、より大きな影響を及ぼし、トランケーションによるスペクトル歪みに加え、深刻な非線形歪みがエコー キャンセル効果に影響を与えます。ポッピング問題を解決するには、AGC アルゴリズムで PC 側のアナログ ゲインを適応的に調整し、マイクを強化する必要があります。
(4) スペクトルの欠落
機器取得側のスペクトル不足は、ハードウェアコールバックのオーディオサンプリングレートが実際のスペクトル分布と一致していないことが主な原因であり、エンコーダが高いエンコードビットレートを与えても高音質にはなりません。ここで紹介した聴覚への効果。
(5) 解決策:
さまざまなビジネス シナリオで機器の可用性を解決し、機器によって収集されるデータの精度を向上させるために、一般的に使用される戦略は次のとおりです。
デバイスの適応:
さまざまなモデルに応じて、Android は適切な取得サンプリング レート、サンプルレート、オーディオモード、オーディオソース、および Java または opensles のどちらが使用されるかを構成配布を通じて適応させます。
ビジネス層の協力戦略:
Windows: DingTalk 会議、ユーザーは dsound または coreaudio の使用を選択できます
SDK の自己適応戦略では、devicemonitor を使用して、デバイスが利用可能か異常かを監視します。異常が発生すると、SDK は次の戦略を採用できます。
オーディオ キャプチャ/再生デバイスを自動的に再起動し、
オーディオ ドライバーを自動的にダウングレードして切り替えます。
2.2 オーディオ 3A
オーディオの前処理は、オーディオ処理チェーン全体の鍵です。マイクで収集した元の音声データにはノイズやエコーなど様々な問題があり、例えば、複数人でのビデオ会議のシーンでは、同じ場所にいる複数の機器が同時にマイクを開くと強いハウリングが発生し、スピーカーがマイクから遠く離れています。音質を向上させるためには、送信側で送信信号に対してエコーキャンセル、ノイズリダクション、音量等化処理、つまりAECエコーキャンセル、ANSノイズ抑制、AGC自動ゲインの3A処理を順番に行う必要があります。コントロール。通話、チャット、教育、ゲームなどのさまざまなシナリオで、リアルタイム オーディオおよびビデオのメーカーは、シナリオの実際のニーズを考慮し、適切なオーディオ効果を実現するために 3A アルゴリズムを調整する必要があります。
webrtc オープン ソース コードでは、Android 側を例にとると、webrtc はハードウェアにハードウェア ANS およびハードウェア AEC 機能があるかどうかを確認し、ある場合はソフトウェア AEC は有効になりません。サポート、ソフトウェア 3A は有効になります。ボトムアップ ソリューションと同様に、ハードウェア 3A の機能がデバイスごとに相対的に異なることが主な理由です。ハードウェア 3A に依存するだけでは、完全に信頼性が高く安定した効果を達成することはできません。以下では、3A の原理とその機能の分析に焦点を当てます。音質への影響。
(1) AEC（音響エコーキャンセレーション）
原理: 以下の図に示すように、Room1 のユーザーは rtc を通じてピア Room2 に話し、ピア スピーカーによって再生された後、ピア マイクによって集音され、エンコードされて Room1 に送信されます。自分の声、つまりいわゆる「エコー」を聞く、AEC が解決しなければならない問題は、相手側に自分の声が聞こえないようにエコー信号を除去することです。したがって、オーディオおよびビデオ通信では、共通の問題は「自分の声が聞こえる」問題です。その理由は、「私」の携帯電話に問題があるのではなく、「私」と通信している他の人たちのエコーキャンセルが適切に処理されていないためです。 「自分の声が聞こえる」。
エコー キャンセルの基本原理は、近端信号 (マイク) によって収集されたエコーを含む信号と遠端基準信号 (再生前の相手側の受信音声信号) との相関を使用することです。エコー信号の相関関係に基づいて、リモート信号モデルが確立され、エコー パスがシミュレートされ、インパルス応答が実際のエコー パスに近づくように適応アルゴリズムが調整されます。そしてマイクで受信した信号から推定値を減算することでエコーキャンセル機能を実現します。
RTC シーンでのエコー キャンセルにはいくつかの問題があります。
ハードウェア AEC の効果はまったく異なります。
ダブルトークの質問。
レイテンシーの推定。
リークエコーなど。
参考記事：https://developer.aliyun.com/article/781449?spm=a2c6h.14164896.0.0.70a21f36aoEDj7
(2) ANS（自動ノイズ抑制）
webRTC の ANS は、ノイズを低減するウィナー フィルタリングに基づいており、受信したノイズを含む音声信号の各フレームについて、フレームの初期ノイズ推定に基づいて、音声確率関数が定義され、各フレームのノイズ信号が測定されます。 、測定された分類特徴を使用して、各フレームの複数特徴ベースの音声確率を計算し、計算された各フレームの特徴ベースの音声確率に従って、計算された音声確率を動的因子 (信号分類特徴としきい値パラメーター) で重み付けします。これは、マルチフレームの各フレームの音声確率関数を修正し、フレームごとに修正された音声確率関数を使用して各フレームの初期ノイズ (連続するマルチフレームの各フレームの分位数ノイズ) 推定値を更新します。
ノイズリダクションが音質に及ぼす影響:
信号の音質に対するノイズ リダクションの影響は、エコー キャンセル モジュールの影響よりも大きくなります。これは、ノイズ リダクション アルゴリズムの設計の開始時に、ノイズ フロアが次のように先験的に仮定されていたためです。安定した信号 (少なくとも短期間安定した信号) であり、この仮定によれば、音楽と背景雑音の間の識別は、音声と背景雑音の間の識別よりもはるかに弱いです。心地よい音楽は各周波数帯域（特に高周波部分）のディテールが豊富であり、いずれかの周波数帯域が失われると聴覚に影響を与える可能性があります。しかし、音楽の中高域（特に高周波）部分はエネルギーが低いことが多く、ノイズ重畳後のS/N比が小さくなり、ANS処理が困難になります。中高周波の音楽の細部がノイズと誤認され、処理され、損傷を引き起こす可能性があります。対照的に、人間の声は一般に中周波数と低周波数に集中しており、エネルギーと信号対雑音比が高く、ANS 処理でのダメージが比較的少ないです。
要約すると、音楽は ANS によって誤って損傷を受ける可能性が高く、高音質が要求される音楽シーンでは、環境レベルからのノイズ干渉を減らすために、ノイズ リダクション レベルを下げるか、ノイズ リダクション処理をオフにすることをお勧めします。できるだけ。
録音された音声:
ANS 後の音声:
(3) AGC（自動利得制御）
すべての信号がボリューム ゲイン コントロールの対象になるわけではありません。ANS/AEC がノイズ/遠端エコーのみを抑制し、近端音声を維持するのと同様に、AGC も、ノイズやエコーを回避するために、収集された信号内の近端音声をスクリーニングする必要があります。およびその他の無関係な信号ゲイン。この点を考慮すると、信号内のノイズとエコーはこの時点で大幅に低減されているため、AGC モジュールを AEC および ANS 処理の後に配置する方が適切です。しかし、立地の「有利」だからといって、AGCが安心して業務を遂行できるわけではありません。ネットのすり抜けを避けるために、多くの場合、音声検出 (VAD) を実行して、音声セグメントと非音声セグメントをさらに区別する必要があります。
AGC にはいくつかの重要なパラメータがあります。
ターゲットボリューム - targetLevelDbfs:ボリュームイコライゼーション結果のターゲット値を示します。1 に設定すると、出力ボリュームのターゲット値が -1dB であることを意味します。
ゲイン能力 - CompressionGaindB:オーディオの最大ゲイン能力を示します。12dB に設定すると、最大値を 12dB 増やすことができます。
AGC の 3 つのモード:
列挙型 {
kAgcMode変更なし、
kAgcModeAdaptiveAnalog, // 適応アナログ モード
kAgcModeAdaptiveDigital, // 適応デジタルゲインモード
kAgcModeFixedDigital // 固定デジタルゲインモード
};
PC 側はアナログ ゲイン調整をサポートしており、PC 側では通常、kAgcModeAdaptiveAnalog が使用され、アナログ ゲインとデジタル ゲインを一緒に調整して音量を調整します。
2.3 エンコーダ
オーパスエンコーダー:
OpusはSILK+CELTを混合したコーデックで、学術名はUSAC、Unify Speech and Audiocodingといい、音楽と音声を区別しないコーデックです。このコーデックには、現在のフレームが音声であるか音楽であるかを判断するための音楽検出器があります。音声はシルク フレームでエンコードされ、音楽はケルト フレームでエンコードされます。一般に、エンコーダが使用するモードを制限しないことをお勧めしますエンコード用。
現在、WebRTC はアプリケーションとして kvoip を使用しており、混合エンコード モードがデフォルトで有効になっています。
エンコーダにおける混合符号化モードでの音楽および音声符号化アルゴリズムの判定:
Opus コーディングには次の特徴があります。
ビットレートは 6 kb/s ～ 510 kb/s
8 kHz (狭帯域) ～ 48 kHz (フル周波数) のサンプリングレート
フレームサイズは2.5msから60msまで
固定ビット レート (CBR) と可変ビット レート (VBR) をサポート
ナローバンドからフルバンドまでのオーディオ帯域幅
音声と音楽をサポート
モノラルとステレオをサポート
最大 255 チャネル (マルチストリーム フレーム) をサポート
ビットレート、オーディオ帯域幅、フレーム サイズを動的に調整可能
損失率とパケット損失隠蔽に対する優れた堅牢性 (PLC)
デザートコードレート:
概要: 音楽シーンなど高音質が求められるシーンでは、より複雑でビットレートの高い Celt エンコードを使用することで、高品質な音楽体験を実現できますが、音声シーンでは、Silk エンコードを使用することができ、さらにビットレートが高くなります。エンコーダのビット レートも非常に重要です。ビット レートが低すぎると、Opus は FB エンコーディングから WB または NB エンコーディングに自動的にダウングレードし、エンコーダ側で「スペクトル トランケーション」効果が発生します。AAC にも同様の現象があります。この部分は、この記事と組み合わせることができます。3.6 のケース分析を見てください。
2.4 ネットテック
Neteq は webrtc の重要なテクノロジであり、主にネットワーク ジッター、パケット損失などに対抗するためのものです。ジッターとは、ネットワーク上の理由により、異なる時間間隔で受信側に到着するデータの不均衡を指します。または、受信側がデータ パケットを受信します。時間間隔はそれぞれ異なりますが、パケットロスとは、ネットワーク上を伝送されたデータパケットがさまざまな理由で失われてしまうことであり、数回再送を行った後、回復パケットとして正常に受信されますが、再送も失敗したり、回復パケットが古くなっています。実際のパケット損失が発生するため、補償するものがない状態から偽のデータを生成するには、パケット損失回復 PLC アルゴリズムが必要です。パケットロスとジッタは時間次元で統一されており、待機期間内に待機したものがジッタ、大幅に遅れて到着したものが再送、待機期間を超えて待機しなかったものが「真のパケットロス」となります。 Neteq の最適化の目標の 1 つは、パケットが「真のドロップ」になる確率を最小限に抑えることです。
NetEQ のコア モジュールには MCU モジュールと DSP モジュールがあり、MCU モジュールはジッタ バッファ キャッシュへのデータの挿入とフェッチ、および DSP の操作を担当し、DSP モジュールは音声情報番号の処理を担当します。デコード、加速、減速、融合、PLCなど。同時に、MCU モジュールはジッター バッファからパケットを取得し、DSP モジュールの関連フィードバックの影響を受けます。MCU モジュールには、バッファに入るオーディオ パケット、バッファからのオーディオ パケットの取り出し、音声パケットの到着間隔によるネットワーク伝送時間遅延の評価、DSP モジュールでの操作 (加速、減速、PLC、マージ) の実行などが含まれます。DSP モジュールには、デコード、デコードされた音声 PCM データに対する関連操作の実行、ネットワーク ジッター レベルの評価、再生可能データの再生バッファへの配信などが含まれます。
Neteq は、実際のパケット損失が発生した場合、パケット損失補償 (パケット損失隠蔽、PLC) アルゴリズムを使用します。PLC アルゴリズムは、取得したすべての情報を使用して失われた音声パケットを適切に補うことができるため、検出が困難になり、受信側の音声の明瞭さと流暢さを確保し、ユーザーに優れた通話体験をもたらします。
RTC リンク全体において、パケット損失は、ネットワーク内でデータが送信されるときによく発生する現象であり、VOIP (Voice Over Internet Phone、VOIP) 通話における音声品質低下の主な原因の 1 つでもあります。従来の PLC ソリューションは主に信号処理の原理に基づいており、基本原理はパケット損失前の復号パラメータ情報を使用して損失音声信号を再構築することです。従来の PLC 方式の最大の利点は、計算が簡単でオンラインで補正できることですが、欠点は補正能力が限られており、効果的に対処できるのは約 40ms のパケット損失のみであることです。長期にわたる連続的なバースト パケット損失に対処する場合、従来のアルゴリズムでは機械音、急激な波形減衰、その他効果的に補償できない状況が発生します。
下図に示すように、パケット損失が 120ms に固定されている場合、neteq_plc アルゴリズムは、単純な遺伝子サイクルの繰り返しと減衰によってパケット損失補償を完了します。パケット部分の波形、opus_plc アルゴリズムの補償能力には限界があるため、効果的に補正できるのは約 40 ミリ秒だけであり、40 ミリ秒を超えるパケット損失は減衰して無音になります。
したがって、リンク全体の音質を改善するには、ネットワーク側と neteq 側で最適化できる技術的な方向性が 2 つあります。
Red/FEC+Nack を通じて弱いネットワークに抵抗する能力を向上させます。
受信側の PLC アルゴリズムを最適化することで、「真のパケット損失」時の聴覚を改善します。
3. さまざまなビジネス シナリオとその背後にあるテクノロジーの選択について考える
3.1 ライブシーン:
生放送のシーンは通常、エンターテインメントベースのシーンです。アンカーは通常、外部サウンド カードを使用して携帯電話で音楽を再生します。この種のシーンは、音質、特に音楽の音質に対する要求が高いのが特徴です。技術的な解決策、ソフトウェア 3A + メディア ボリューム バーが通常使用されます +音楽エンコーディング スキーム、および rtc は通常、外部サウンド カードに接続されている場合、サウンドに 3A 処理を実行しません。サウンド カードに接続されていない場合は、また、弱いモードのノイズ リダクションを使用するか、ノイズ リダクションを直接オフにします。
3.2 会議風景:
会議シーンは典型的な音声通話ベースのシーンです。そのため、Tencent ConferenceとDingTalk Conferenceは一般にハードウェア3Aモード、通話音量バー、音声コーディングを採用しています。下の写真はDingTalk会議モバイル端末です。この解決策の欠点も明らかです。つまり、収集された音源の実効帯域幅はすでに非常に低く、ハードウェア 3A によって処理されています。 、その後オフにすると、ソフトウェア 3A にはほとんどメリットがありません。
Tencent Conference のクライアントも同じソリューションです。
3.3 通信シナリオ:
WeChat ビデオ通話を例にとると、これは典型的な通信シナリオであり、通信シナリオと会議シナリオにおける音質技術の選択は同じソリューション、つまりハードウェア 3A + 通話音量バーのソリューションですが、WeChat 通話は会議中の音楽の設定やモードの機能は提供しません。
3.4 オンライン教育シナリオ:
オンライン教育シナリオは、通常のオンライン教育シナリオと音楽教育シナリオに細分化されており、前者は音声講義を中心としたもの、後者はピアノなどの楽器演奏を中心としたものであり、それぞれに特徴があります。
一般教育のシナリオ:
一般的な教育シナリオでは、音質の観点から、クリアで明瞭な音声品質を確保することが主な目的であるため、一般的なソリューションは、通信シナリオと同様のハードウェア 3A ソリューションを使用することです。
音楽教育現場：
音楽教育の現場は本質的に生放送の現場と同様であり、一種の汎エンターテインメントの現場でもありますが、その背後にある技術選定においても音質を重視する必要があります。 3A 取得 + 音楽ノイズリダクション + 音楽エンコード;
3.5 「一緒に見る」シーン
「一緒に見る」シーンとは、同じ部屋で複数人で同じ動画をリアルタイムにボイスチャットしながら視聴するシーンのことで、「一緒に映画を鑑賞する」や、ビデオコースウェアをプレイするなどの応用シーンやその拡張シーンがこれにあたります。教育教室の教師 オンラインのクラスメートが一緒に視聴したり、オンラインのビデオプロットが散りばめられたスクリプトキリングゲームなどのシーンで視聴したりできます。
下の写真は、このシーンの典型的なトップ 1 アプリ「Shimmer」です。
このシナリオの技術的な問題点は、プレーヤー SDK と rtc SDK が 2 つの SDK であることです。プレーヤーのサウンドのエコー キャンセルの問題を解決するにはどうすればよいですか。そうしないと、会議の参加者にはムービーのサウンドが 2 回聞こえてしまいます。また、エコーが存在すると、ムービー内の人間の声がプレーヤーの再プレイ時に音声アクティベーションをトリガーし、ユーザーが画面上で話さなくても、ムービー内のキャラクターの声に合わせて UI の音波が振動します。 UI. したがって、このシナリオの難しさは、ムービー エコーを除去することです。このシナリオには、現在 3 つの解決策があります。
解決策 1: ハードウェア 3A、この解決策は実装が簡単で、ムービー エコーを排除するためにハードウェア 3A に依存しています。現在、オンライン バージョンの Shimmer はこの解決策を使用していますが、この解決策にはいくつかの問題があります。
Android には 2 つの音量バーがあります。プレーヤーはメディアの音量バー、ボイス チャットの rtcsdk は通話の音量バーであるため、ユーザー エクスペリエンスはあまり良くありません。デフォルトではマイク上のユーザーが通話の音量を調整します。メディアの音量は個別に調整する必要があります。
Android ハードウェア 3A のさまざまなモデルの AEC 効果には一貫性がなく、一部の Android モデルではエコー キャンセルが不十分なことが原因でエコー漏れの問題が発生しますが、これは解決できず、エクスペリエンスは良好ではありません。
iOS 側でもハードウェア 3A ソリューションを使用できますが、ハードウェア 3A とメディアのボリュームが同時に存在する場合、プレーヤーの音量が最大でも、実際の映画のサウンドはまだ非常に小さいです。この状況はユーザー エクスペリエンスに深刻な影響を与えます。
オプション 2: オプション 2 とオプション 3 の中心となるアイデアは、レンダリング前にプレーヤーからオーディオ基準信号を取得し、それをエコー キャンセル用のリモート基準信号としてソフトウェア aec に送信し、それによってエコーを排除することです。とオプション 3 は統合可能です。メディア ボリューム バーを使用すると、rtc は純粋なソフト 3A ソリューションに接続され、ソリューション 1 の 3 つのエクスペリエンス問題をうまく解決できます。
3番目の解決策:
ソリューション 3 はさらに進化したソリューションで、アンカーの再生進行状況を rtc シグナリング チャネルを通じて Lianmai 端末に同期して、再生進行状況の同期を実現することもできます。ビジネス レイヤーのロジックを簡素化し、パフォーマンスも達成できます。
3.6 ケーススタディ:
背景: ヘッド エンターテイメント シーンで、rtcsdk にアクセスした後、ホストは外部サウンド カードで音楽が再生され、音質が悪く、聴衆が聞く音質も良くないと報告しました。
原因分析:
SDK 側: アンカー A が外部サウンド カードを使用して BGM をプッシュすると、アンカー B が聞く音楽の音質が良くありません。主な理由は、3A アルゴリズム ライブラリの ANS (自動ノイズ低減アルゴリズム) が存在することです。一部のシナリオ セルフテストにより音楽が損傷します。原因はありますが、スペクトルの切り捨ては発生しません。最適化後に解決されます。
サーバー側: MPU が 2 つのアンカーのストリームを取得して混合し、AAC ストリームにトランスコードする場合、AAC Audioprofile パラメータ セットは LC、64kbps、1ch です。このパラメータ セットのコード レートが AAC の帯域幅につながります。 16kHz のみ、つまりスペクトルの切り詰めです。入力がモノラル、48000 オーディオ、ビット レート 64kbps の場合、AAC LC モードは帯域幅と聴力の点で AAC HEv1/HEv2 モードよりも劣ります。
3.7 業界の進化トレンド:
ハードウェア 3A は実装が簡単で消費電力が比較的低いため、長い間 RTC 分野の主要な技術ソリューションでしたが、ソフトウェアの発展により 3A 技術はますます成熟しており、現在は最先端のソフトウェア 3A 全体的なソリューションは、すでに音声と音楽コンテンツに基づいている可能性があります。調整アルゴリズム戦略に適応し、ハードウェア 3A の「致命傷」 - 収集された音声の低品質と体験の大きな違いさまざまな Android デバイスの導入により多大な適応コストが発生し、RTC の最先端技術トレンドは徐々に純粋な Software 3A の進化へと移行してきました。純粋なソフトウェア 3A は、さまざまなシナリオでより一貫した高品質のサウンド体験をユーザーに提供し、RTC メーカーの適応人材と技術コストを大幅に削減できますが、十分な 3A アルゴリズム機能のサポートも必要です。
一連の SDK を使用してさまざまなビジネス シナリオにおけるさまざまな音質要件を満たすために、rtc メーカーはさまざまな AudioProfile を提供して区別し、ユーザーに設定を提供します。詳細については、付録 II を参照してください。
4. 概要:
この記事では、オーディオ機器の取得、3A 処理、エンコーダー、neteq に至るまで、RTC シナリオにおける一般的なオーディオ エンジン アーキテクチャを組み合わせ、技術的な幅から音質に影響を与える要因を 1 つずつ分析します。この記事では、会議、教育、エンターテイメントなどのさまざまなシナリオにおける音質に対するさまざまな要件を組み合わせて、さまざまなビジネス シナリオにおけるオーディオ戦略とソリューション選択の考慮事項を詳しく説明し、最後に業界の進化トレンドについて個人的な分析と予測を行います。
付録 1: VOIP モードでの 8Khz のみの取得帯域幅の調査
現象：
APP 層が同じサンプリング レート設定で AudioRecord コレクションを作成する場合、異なるオーディオモードによって収集される有効帯域幅は異なります。voip モードでは、収集される有効帯域幅はわずか 8khz ですが、通常モードの帯域幅は通常の全周波数ですバンドデータ; (この現象は iOS プラットフォームにも存在します)、携帯電話やチップとは関係ありません。
理由
voip の帯域幅が 8khz のルートケースはどこにありますか? (ハードウェア 3a が 16khz をサポートしていると思われ、ハードウェア 3a の前後でリサンプルが行われています)
理由: 例として Qualcomm チップ、SRC は AudioDSP 内にあり、voip モードでは、enc はオプションで、フロント SRC は 16 khz にダウンサンプリングされ、audiodsp は 48 khz にアップサンプリングされ、48 khz データが AP 層に与えられます。 ; MTK チップの SRC ロジックは AudioDSP の外部にあります; 中心的な理由は、ハードウェア 3A が 16khz のみをサポートしていることですが、一方では、dsp の消費電力を考慮したためです (aec アルゴリズムの複雑さは比較的高い)、一方、voip の音声コーディングは通常 8khz/16khz の音声コーディングのみをサポートしているためです。
関連情報:
https://www.cnblogs.com/talkaudiodev/p/8996338.html
https://www.cnblogs.com/talkaudiodev/p/8733968.html
解決策の探索
解決策 1: ios: kAUVoiceIOProperty_BypassVoiceProcessing と同様のバイパス モードの導入を検討できます。
https://developer.apple.com/documentation/audiotoolbox/1534007-voice-processing_i_o_audio_unit_proper
iOS のバイパス モードによって解決される問題: voip モードでは、通話音量バーの下でハードウェア 3A が有効になりません。
解決策 2: ネイティブ Android システムの制御ロジックをハードウェア 3A スイッチに適応させる
所得
ハードウェア 3A 戦略は、1 つの音量バー (通話音量バー) で最適な音質設定を実現するために個別に制御でき、APP 開発者にさらに多くの再生方法を提供します。
特定のアプリケーション シナリオ: 音量バー (0 に調整できない) と高音質が必要なシナリオ、例: 音楽教育シナリオ。
装備の違い
Huawei mate30:
audiomode: MODE_IN_COMMUNICATION + audiosource: VOICE_COMMUNICATION 録音は 8khz 帯域幅です (おそらく電力消費を考慮したため)
ワンプラス 10R 5G：
audiomode: MODE_IN_COMMUNICATION + audiosource: VOICE_COMMUNICATION、ハードウェア AEC を有効にすると、帯域幅は損傷しませんが、オーディオトラック スレッドが開始されている場合、AEC ロジックがトリガーされ、帯域幅が減少します。
付録 II: AudioProfile の関連定義
サウンド ネットワークの関連インターフェイス ドキュメントを参照してください: https://docportal.shengwang.cn/cn/All/API%20Reference/java_ng/API/toc_audio_process.html#ariaid-title36
public abstract int setAudioProfile(int profile, int scenario);
エンコードモード（プロファイル）
瞬時の送信コードレートの対応関係はあくまでも目安の範囲であり、参考値であり、通常、qos はネットワークの状況に応じて冗長パケット数と符号化対象のコードレートを動的に調整します。
シーンモード:
シナリオ モード (シナリオ) は、オーディオ デバイスのパラメーター、ソフトウェア 3A 戦略、関連する Qos 戦略などに影響し、エンコード ビット レートとは関係がありません。さまざまなビジネス シナリオ、さまざまな音質、および関連する技術指標が選択に使用されます。 。
付録 III: 参考文献:
シンプルな WebRTC AEC (音響エコー キャンセル: https://developer.aliyun.com/article/781449?spm=a2c6h.14164896.0.0.70a21f36aoEDj7)
WebRTC オーディオ NetEQ の解釈と現地語での最適化実践: https://developer.aliyun.com/article/782756
RTC オーディオ エクスペリエンスの向上 - ハードウェアを理解することから始めます: https://developer.aliyun.com/article/808257
低遅延・高音質を詳しく解説｜エコーキャンセルとノイズリダクション：https://www.rtcdeveloper.cn/cn/community/blog/21147