詳解 WebRTC 高音質低延時的背後 — AGC

時間 2021-06-13

標籤 git 算法 windows 數組 app 框架函數性能學習優化欄目 Git 简体版

原文原文鏈接

簡介：本文將結合實例全面解析 WebRTC AGC 的基本框架，一塊兒探索其基本原理、模式的差別、存在的問題以及優化方向。git

前面咱們介紹了 WebRTC 音頻 3A 中的聲學回聲消除（AEC：Acoustic Echo Cancellation）的基本原理與優化方向，這一章咱們接着聊另一個 "A" -- 自動增益控制（AGC：Auto Gain Control）。本文將結合實例全面解析 WebRTC AGC 的基本框架，一塊兒探索其基本原理、模式的差別、存在的問題以及優化方向。算法

做者｜珞神windows

審校｜泰一數組

前言

自動增益控制（AGC：Auto Gain Control）是我認爲鏈路最長，最影響音質和主觀聽感的音頻算法模塊，一方面是 AGC 必須做用於發送端來應對移動端與 PC 端多樣的採集設備，另外一方面 AGC 也常被做爲壓限器做用於接收端，均衡混音信號防止爆音。設備的多樣性最直接的體現就是音頻採集的差別，通常表現爲音量過大致使爆音，採集音量太小對端聽起來很吃力。app

在音視頻通話的現實場景中，不一樣的參會人說話音量各有不一樣，參會用戶須要頻繁的調整播放音量來知足聽感的須要，戴耳機的用戶隨時承受着大音量對耳朵的「暴擊」。所以，對發送端音量的均衡在上述場景中顯得尤其重要，優秀的自動增益控制算法可以統一音頻音量大小，極大地緩解了由設備採集差別、說話人音量大小、距離遠近等因素致使的音量的差別。框架

AGC 在 WebRTC 中的位置

在講 AGC 音頻流處理框架以前，咱們先看看 AGC 在音視頻實時通訊中的位置，如圖 1 展現了同一設備做爲發送端音頻數據從採集到編碼，以及做爲接收端音頻數據從解碼到播放的過程。AGC 在發送端做爲均衡器和壓限器調整推流音量，在接收端僅做爲壓限器防止混音以後播放的音頻數據爆音，理論上推流端 AGC 作的足夠魯棒以後，拉流端僅做爲壓限器是足夠的，有的廠家爲了進一步減少混音以後不一樣人聲的音量差別也會再作一次 AGC。圖 1 WebRTC 中音頻信號上下行處理流程框圖函數

AGC 的核心參數

先科普一下樣本點幅度值 Sample 與分貝 dB 之間的關係，以 16bit 量化的音頻採樣點爲例：dB = 20 * log10（Sample / 32768.0），與 Adobe Audition 右側縱座標刻度一致。性能

幅度值表示：16bit 採樣最小值爲 0，最大值絕對值爲 32768（幅度值以下圖右邊欄縱座標）。學習

分貝表示：最大值爲 0 分貝（分貝值以下圖右邊欄縱座標），通常音量到達 -3dB 已經比較大了，3 也常常設置爲 AGC 目標音量。優化

核心參數有：

typedef struct {
  int16_t targetLevelDbfs;    // 目標音量
  int16_t compressionGaindB;  // 增益能力
  uint8_t limiterEnable;      // 壓限器開關
} AliyunAgcConfig;

目標音量 - targetLevelDbfs：表示音量均衡結果的目標值，如設置爲 1 表示輸出音量的目標值爲 - 1dB;

增益能力 - compressionGaindB：表示音頻最大的增益能力，如設置爲 12dB，最大能夠被提高 12dB；

壓限器開關 - limiterEnable：通常與 targetLevelDbfs 配合使用，compressionGaindB 是調節小音量的增益範圍，limiter 則是對超過 targetLevelDbfs 的部分進行限制，避免數據爆音。

AGC 的核心模式

除了以上三個核心的參數外，針對不一樣的接入設備 WebRTC AGC 提供瞭如下三種模式：

enum {
  kAgcModeUnchanged,
  kAgcModeAdaptiveAnalog,  // 自適應模擬模式
  kAgcModeAdaptiveDigital, // 自適應數字增益模式
  kAgcModeFixedDigital  // 固定數字增益模式
};

如下咱們會結合實例從基本功能，適用場景，信號流圖以及存在的問題等方面闡述這三個模式。

固定數字增益 - FixedDigital

固定數字增益模式最基礎的增益模式也是 AGC 的核心，其餘兩種模式都是在此基礎上擴展獲得。主要是對信號進行固定增益的放大，最大增益不超過設置的增益能力 compressionGaindB，結合 limiter 使用的時候上限不超過設置的目標音量 targetLevelDbfs。

固定數字增益模式下僅依靠核心函數 WebRtcAgc\_ProcessDigital 對輸入信號音量進行均衡，因爲沒有反饋機制，其信號處理流程也是極其簡單，設置好參數以後信號會通過以下流程：

固定數字增益模式是最核心的模式，主要有以下兩個方面值得咱們深刻學習：

語音檢測模塊 WebRtcAgc\_ProcessVad 的基本思想

在實時通訊的場景中，麥克風採集的近端信號中會存在遠端的信號的成分，流程中會先經過 WebRtcAgc\_ProcessVad 函數對遠端信號進行分析，在探測實際近端信號包絡的時候須要剔除遠端信號這個干擾項，避免因殘留的回聲信號影響了近端信號包絡等參數的統計。最傳統的 VAD 會基於能量，過零率和噪聲門限等指標區分語音段和無話段，WebRTC AGC 中爲粗略的區分語音段提供了新的思路：

計算短時均值和方差，描述語音包絡瞬時變化，可以準確反映語音的包絡，如圖 2 左紅色曲線；

// update short-term estimate of mean energy level (Q10)
tmp32 = state->meanShortTerm * 15 + dB;
state->meanShortTerm = (int16_t)(tmp32 >> 4);
// update short-term estimate of variance in energy level (Q8)
tmp32 = (dB * dB) >> 12;
tmp32 += state->varianceShortTerm * 15;
state->varianceShortTerm = tmp32 / 16;
// update short-term estimate of standard deviation in energy level (Q10)
tmp32 = state->meanShortTerm * state->meanShortTerm;
tmp32 = (state->varianceShortTerm << 12) - tmp32;
state->stdShortTerm = (int16_t)WebRtcSpl_Sqrt(tmp32);

2. 計算長時均值和方差，描述信號總體緩慢的變化趨勢，勾勒信號的「重心線」，比較平滑有利於利用門限值做爲檢測條件，如圖 2 左藍色曲線；

// update long-term estimate of mean energy level (Q10)
tmp32 = state->meanLongTerm * state->counter + dB;
state->meanLongTerm = WebRtcSpl_DivW32W16ResW16(tmp32, WebRtcSpl_AddSatW16(state->counter, 1));
// update long-term estimate of variance in energy level (Q8)
tmp32 += state->varianceLongTerm * state->counter;
state->varianceLongTerm = WebRtcSpl_DivW32W16(tmp32, WebRtcSpl_AddSatW16(state->counter, 1));

3. 計算標準分數，描述短時均值與「重心線」的誤差，位於中心之上的部分能夠認爲發生語音活動的可能性極大；

tmp32 = tmp16 * (int16_t)(dB - state->meanLongTerm);
tmp32 = WebRtcSpl_DivW32W16(tmp32, state->stdLongTerm);
state->logRatio = (int16_t)(tmp32 >> 6);

圖 2 左：長短時均值與方差 右：輸入與 vad 檢測門限

WebRtcAgc\_ProcessDigital 如何對音頻數據進行增益

3 個核心參數都是圍繞固定數字增益模式展開的，咱們須要搞清楚的是 WebRTC AGC 中核心函數 - WebRtcAgc\_ProcessDigital 是如何對音頻數據進行增益的。

1. 根據指定的 targetLevelDbfs 和 compressionGaindB，計算增益表 gainTable；

/* 根據設置的目標增益與增益能力，計算增益表gainTable */
if (WebRtcAgc_CalculateGainTable(&(stt->digitalAgc.gainTable[0]), stt->compressionGaindB, stt->targetLevelDbfs, stt->limiterEnable, stt->analogTarget) == -1) {
    return -1;
 }

這一步中增益表 gainTable 能夠理解爲對信號能量值（幅值的平方）的量化，咱們先固定 targetLevelDbfs，分別設置 compressionGaindB 爲 3dB~15dB，所對應的增益表曲線以下，能夠看到增益能力設置越大，曲線越高，以下圖。

你們可能會好奇增益表 gainTable 的長度爲何只有 32 呢？32 其實表示的是一個 int 型數據的 32 位（short 型數據的能量值範圍爲 [0, 32768^2] 能夠用無符號 int 型數據表示），從高位到低位，爲 1 的最高位具備最大的數量級稱爲整數部分 - intpart，後續數位組成小數部分稱爲 fracpart。所以 [0, 32768] 之間的任意一個數都對應數字增益表中的一個增益值。接下來咱們講講如何查表並應用增益值完成音量均衡。

/** 部分關鍵源碼 */
/** 提取整數部分和小數部分 */
intPart = (uint16_t)(absInLevel >> 14);          // extract the integral part
fracPart = (uint16_t)(absInLevel & 0x00003FFF);  // extract the fractional part
......
/** 根據整數部分和小數部分生成數字增益表 */
gainTable[i] = (1 << intPart) + WEBRTC_SPL_SHIFT_W32(fracPart, intPart - 14);

2. 根據輸入信號包絡在增益表 gainTable 中查找增益值，並應用增益到輸入信號；

基於人耳的聽覺曲線，AGC 中在應用增益是是分段的，一幀 160 個樣本點會分爲 10 段，每段 16 個樣本點，所以會引入分段增益數組 gains，下述代碼中描述了數字增益表與增益數組的關係，直接體現了查表的過程，其思想與計算增益表時類似，也是先計算整數部分與小數部分，再經過增益表組合計算出新的增益值，其中就包含了小數部分的補償。

// Translate signal level into gain, using a piecewise linear approximation
    // find number of leading zeros
    zeros = WebRtcSpl_NormU32((uint32_t)cur_level);
    if (cur_level == 0) {
      zeros = 31;
    }
    tmp32 = (cur_level << zeros) & 0x7FFFFFFF;
    frac = (int16_t)(tmp32 >> 19);  // Q12.
    tmp32 = (stt->gainTable[zeros - 1] - stt->gainTable[zeros]) * frac;
    gains[k + 1] = stt->gainTable[zeros] + (tmp32 >> 12);

下述代碼是根據分段增益數組 gains，右移 16 位後得到實際的增益值（以前計算增益表和增益數組都是基於樣本點能量，這裏右移 16 位能夠理解成找到一個整數 α，使得信號幅度值 sample 乘以 α 最接近 32768），直接乘到輸出信號上（這裏的輸出信號在函數開始已經被拷貝了輸入信號）。

/** 增益數組gains做用到輸出信號，完成音量均衡  */
  for (k = 1; k < 10; k++) {
    delta = (gains[k + 1] - gains[k]) * (1 << (4 - L2));
    gain32 = gains[k] * (1 << 4);
    // iterate over samples
    for (n = 0; n < L; n++) {
      for (i = 0; i < num_bands; ++i) {
        tmp32 = out[i][k * L + n] * (gain32 >> 4);
        out[i][k * L + n] = (int16_t)(tmp32 >> 16);
      }
      gain32 += delta;
    }
  }

咱們以 compressionGaindB = 12dB 的曲線爲例，上圖爲計算的數字增益表 gainTable 的實際值，下圖爲右移 16 位以後獲得的實際增益倍數。能夠看到 compressionGaindB = 12dB 時，整數部分最大增益爲 3，理論上增益 12dB 其實是放大了 4 倍，這裏整數部分最大能夠乘上 3 倍，後續再由小數部分補充剩餘的 0~1.0 倍，從而能夠防止爆音。簡單舉兩個例子：

A. 幅度值爲 8000 的數據，包絡 cur\_level = 8000^2 = 0x3D09000，經過 WebRtcSpl\_NormU32 ((uint32\_t) cur\_level); 計算獲得前置 0 有 6 個，查表獲得整數部分增益爲 stt->gainTable [6] = 3，即 8000 能夠大膽乘以 3 倍，以後增益倍數小於 1.0 的部分由 fracpart 決定；

B. 幅度值爲 16000 的數據，包絡 cur\_level = 16000^2 = 0xF424000，經過 WebRtcSpl\_NormU32 ((uint32\_t) cur\_level); 計算獲得前置 0 有 4 個，查表獲得整數部分增益爲 stt->gainTable [4] = 2，此時會發現 16000 * 2 = 32000，以後均衡到目標音量的過程由 limiter 決定，細節這裏不展開。

簡單說就是，[0, 32768] 中的任何一個數想要增益指定的分貝且結果又不超過 32768，都能在數字增益表 gainTable 中找到肯定的元素知足這個要求。

關於目標增益 targetLevelDbfs 和 Limiter 的應用在 WebRtcAgc\_ProcessDigital 以及相關函數中均有體現，這裏就不展開闡述，你們能夠走讀源碼深刻學習。

下面咱們用幾個 case 來看看固定數字增益模式的效果和存在的問題，先固定設置 targetLevelDbfs = 1, compressionGaindB = 12。

採集音量較小，均衡後改善不明顯；

設備採集音量 - 24dB, 均衡後音量只有 - 12dB，總體音量聽感上會以爲偏小；

2. 採集音量較大，底噪明顯加強；

設備採集音量 - 9dB, 均衡後音量達到 - 1dB，總體音量聽感上正常，但語音幀間起伏減少，主要是無話段的噪聲部分獲得較大提高。這個狀況下主要的問題就是當採集音量自己就比較大時，若是環境噪聲較大，且降噪能力不強時，一旦 compressionGaindB 設置較大，那麼語音部分會被限制在 targetLevelDbfs，可是無話段部分底噪會獲得全量的提高，對端參會人能夠聽到明顯的噪聲。

3. 採集聲音起伏較大（以人爲拼接的由大到小的音頻爲例），均衡後依然沒法改善；

自適應模擬增益 - AdaptiveAnalog

在講自適應模擬增益以前，咱們須要明確 PC 端影響採集音量的功能：

1. PC 端支持調節採集音量，調節範圍爲 0~1.0，WebRTC 客戶端代碼內部映射到了 0~255；

/** 以mac爲例，麥克風靈敏度被轉成了0~255 */
int32_t AudioMixerManagerMac::MicrophoneVolume(uint32_t& volume) const {
  ......
    // vol 0.0 to 1.0 -> convert to 0 - 255
    volume = static_cast<uint32_t>(volFloat32 * 255 + 0.5);
    ......
  return 0;
}

2. 絕大多數 windows 筆記本設備內置了麥克風陣列，並提供麥克風陣列加強算法，降噪的同時還會額外提供 0~10dB 的增益（不一樣機型範圍不一樣，聯想的設備增益高達 36dB），如圖 3；
圖 3 左：MAC 端模擬增益調節右：Windows 端麥克風陣列自帶的增益能力

因爲控制音量的模塊過多，致使 PC 端 AGC 算法更加敏感。線上不少客戶設置的默認值並不合理，這會直接影響音視頻通話的體驗：

1. 採集音量過大會致使噪聲被明顯提高，人聲爆音；

2. 採集音量過大會致使播放的信號回採到麥克風以後有較大的非線性失真，對回聲消除算法是不小的挑戰；

3. 採集音量太小，數字增益能力有限致使對端聽不清；

絕大多數用戶在察覺到聲音異常後並不知道 PC 設備還具有手動調節採集增益的功能，依賴於線上用戶（尤爲是教育場景不少是小學生）本身去調節模擬增益值幾乎不可能，將模擬增益值動態調節的功能作到 AGC 算法內部更可行，配合數字增益部分將近端信號均衡到理想的位置，所以，WebRTC 科學家開發設計了自適應模擬增益模式，經過反饋機制來調節原始採集音量，目標就是與數字增益模塊相互配合，找到最合適的麥克風增益值並反饋給設備層，使得近端數據再通過數字增益以後達到目標增益，音頻數據流框圖以下：

在固定數字增益的基礎上主要有兩處新增：

1. 在數字增益以後，新增了模擬增益更新模塊：WebRtcAgc\_ProcessAnalog，會根據當前模擬增益值 inMicLevel（WebRTC 中將尺度映射到 0~255）等中間參數，計算下一次須要調節的模擬增益值 outMicLevel，並反饋給設備層。

// Scale from VoE to ADM level range.
uint32_t new_voe_mic_level = shared_->transmit_mixer()->CaptureLevel();
if (new_voe_mic_level != voe_mic_level) {
    // Return the new volume if AGC has changed the volume.
    new_mic_volume = static_cast<int>((new_voe_mic_level * max_volume +static_cast<int>(kMaxVolumeLevel / 2)) / kMaxVolumeLevel);
    return new_mic_volume;
}

2. 有些設備商麥克風陣列默認設置比較小，即便將模擬增益調滿採集依然很小，此時就須要數字增益補償部分來改善：WebRtcAgc\_AddMic，能夠在原始採集的基礎上再放大 1.0~3.16 倍，如圖 4。那麼，如何判斷放大不夠呢？上一步中模擬增益更新模塊最終輸出實際爲 micVol 與最大值 maxAnalog（255）之間較小的那個：

*outMicLevel = WEBRTC_SPL_MIN(stt->micVol, stt->maxAnalog) >> stt->scale;

即根據相關的規則計算獲得的實際值 micVol 是有可能大於規定的最大值 maxAnalog 的，也就意味着將模擬增益調整到最大也沒法達到目標音量，WebRtcAgc\_AddMic 會監控這種事件的發生，並會經過查表的方式給予額外的補償。

增益表 kGainTableAnalog：

static const uint16_t kGainTableAnalog[GAIN_TBL_LEN] = {
    4096, 4251, 4412, 4579,  4752,  4932,  5118,  5312,  5513,  5722, 5938,
    6163, 6396, 6638, 6889,  7150,  7420,  7701,  7992,  8295,  8609, 8934,
    9273, 9623, 9987, 10365, 10758, 11165, 11587, 12025, 12480, 12953};
// apply gain
sample = (in_mic[j][i] * gain) >> 12; // 通過右移以後，數組被量化到0~3.16.

圖 4 增益表的增益曲線

每次以 1 的固定步長補償輸入信號，gainTableIdx = 0 表示放大倍數爲 1 倍，即什麼也不作。

/* Increment through the table towards the target gain.
 * If micVol drops below maxAnalog, we allow the gain
 * to be dropped immediately. */
if (stt->gainTableIdx < targetGainIdx) {
    stt->gainTableIdx++;
} else if (stt->gainTableIdx > targetGainIdx) {
    stt->gainTableIdx--;
}
gain = kGainTableAnalog[stt->gainTableIdx];
// apply gain
sample = (in_mic[j][i] * gain) >> 12;

存在的問題：

1. 無語音狀態下的模擬值上調行爲；

2. 調整幅度過大，形成明顯的聲音起伏；

3. 頻繁調整操做系統 API，帶來沒必要要的性能消耗，嚴重的會致使線程阻塞；

4. 數字部分增益能力有限，沒法與模擬增益造成互補；

5. 爆音檢測不是很敏感，不能及時下調模擬增益；

6. AddMic 模塊精度不夠，補償過程當中存在爆音的風險爆音。

自適應數字增益 - AdaptiveDigital

基於音頻視頻通訊的娛樂、社交、在線教育等領域離不開多種多樣的智能手機和平板設備，然而這些移動端並無相似 PC 端調節模擬增益的接口。聲源與設備的距離，聲源音量以及硬件採集能力等因素都會影響採集音量，單純依賴固定數字增益效果十分有限，尤爲是多人會議的時候會明顯感覺到不一樣說話人的音量並不一致，聽感上音量起伏較大。

爲了解決這個問題，WebRTC 科學家仿照了 PC 端模擬增益調節的能力，基於模擬增益框架新增了虛擬麥克風調節模塊：WebRtcAgc\_VirtualMic，利用兩個長度爲 128 的數組：增益曲線 - kGainTableVirtualMic 和抑制曲線 - kSuppressionTableVirtualMic 來模擬 PC 端模擬增益（增益部分爲單調遞增的直線，抑制部分爲單調遞減的凹曲線），前者提供 1.0~3.0 倍的增益能力，後者提供 1.0~0.1 的下壓能力。

圖 5 增益曲線與抑制曲線

核心邏輯邏輯與自適應模擬增益一致。

與自適應模式增益模式同樣，依然利用 WebRtcAgc\_ProcessAnalog 更新 micVol；

根據 micVol 在 WebRtcAgc\_VirtualMic 模塊中更新增益下標 gainIdx，並查表獲得新的增益 gain；

/* 設置指望的音量水平 */
  gainIdx = stt->micVol;
  if (gainIdx > 127) {
    gain = kGainTableVirtualMic[gainIdx - 128];
  } else {
    gain = kSuppressionTableVirtualMic[127 - gainIdx];
  }

3. 應用增益 gain，期間一旦檢測到飽和，會逐步遞減 gainIdx;

/* 飽和檢測更新增益 */
if (tmpFlt > 32767) {
    tmpFlt = 32767;
    gainIdx--;
    if (gainIdx >= 127) {
        gain = kGainTableVirtualMic[gainIdx - 127];
    } else {
        gain = kSuppressionTableVirtualMic[127 - gainIdx];
    }
}
if (tmpFlt < -32768) {
    tmpFlt = -32768;
    gainIdx--;
    if (gainIdx >= 127) {
        gain = kGainTableVirtualMic[gainIdx - 127];
    } else {
        gain = kSuppressionTableVirtualMic[127 - gainIdx];
    }
}

4. 增益後的數據傳入 WebRtcAgc\_AddMic，檢查 micVol 是否大於最大值 maxAnalog 決定是否須要激活額外的補償。

音頻數據流框圖以下：

存在的問題與自適應模式增益類似，這裏須要明確說的一個問題是數字增益自適應調節靈敏度不高，當輸入音量起伏時容易出現塊狀拉昇或壓縮，用一個比較明顯的例子說明：遇到大音量時須要調用壓縮曲線，若是後面緊跟較小音量，會致使小音量進一步壓縮，接着會調大增益，此時小音量後續若是接着跟大音量，會致使大音量爆音，須要 limiter 參與壓限，對音質是存在失真的。