本篇是「詳解低延時高音質系列」的第三篇技術分享。我們這次要將視角放大，從整個音頻引擎鏈路的角度，來講講在時變的網絡下，針對不同的應用場景，如何權衡音質和互動的實時性。
當我們在討論實時互動場景下的低延時、高音質的時候，我們其實要面對的是從端到端整個音頻引擎鏈路上的音質問題。我們在第一篇文章中，簡單的描繪過一條音頻傳輸的過程，如果在該基礎上再進一步細化，音頻引擎的整個鏈路包含以下各步驟：
1. 采集設備對聲學信號進行采樣，形成計算機可操作的離散音頻信號；
2. 由于音頻信號的短時相關性，將音頻信號進行分幀處理，經過 3A 解決方案處理聲學、環境噪音、回聲、自動增益等問題；
3. 編碼器對音頻信號進行實時壓縮，形成音頻碼流；
4. 根據 IP+UDP+RTP+Audio Payload 的格式組包后發送端將音頻數據包發向網絡，重組經過網絡到達接收端的數據包；
5. 經過抗抖緩存和解碼器重建連續的音頻流，播放設備將連續的音頻流播放出來。
在以上不同的音頻處理環節中，都會不可避免地對音頻信號產生一些損傷。我們將上述因采集、播放而對音頻信號引入的損傷稱為「設備損傷」，在環節 2 引入的損傷稱為「信號處理損傷」，在編碼與解碼過程中引入的稱為「編碼損傷」，環節 4 中的稱為「網絡損傷」。
如果要為用戶提供全頻帶的高質量音頻互動體驗，就需要在上述的音頻引擎鏈路支持全頻帶的處理，并在一些約束條件下（比如來自設備、網絡帶寬、聲學環境等），將各個環節引入的損傷盡可能降低到最小。
當音頻數據進入網絡，它會遇到……
如果將網絡視作信息的公路，那么音頻數據包就像是一輛輛跑在公路上的車。這輛車從北京開到上海，途徑的高速公路就是主干網絡，崎嶇山路就是弱網環境。假設每分鐘都有一輛車從北京出發上路，那么他們會遇到三個實時傳輸中的常見問題：丟包、延時、抖動。
丟包
“丟包”指的是有的車無法在有效時間內無法達到終點，甚至可能永遠也到不了終點。有的車可能永遠堵在北京的三環上了，有的車可能中途出了車禍。假如我們的一百輛車里有五輛車因為各種原因沒能按時到達上海，我們這次車隊傳輸的“丟包率”就是 5%。是的，互聯網傳輸也一樣，它并不是百分百可靠的，總有數據無法按時傳輸到目的地。
延時
“延時”指的是每輛車從北京鳥巢開到上海的平均時間。顯然，車隊走高速公路肯定要比走各種小公路快很多，而且從鳥巢出發沿著怎樣的路線開上高速公路也有很大影響，萬一堵在了三環可就要多花好幾個小時了。所以這個值和車隊選擇的行駛路線有關。互聯網傳輸也是一樣的道理，需要傳輸數據的兩點之間經常是有很多可選路徑的，而這些路徑的延時往往相差很大。
抖動
“抖動”指的是車子到達的順序、間隔和出發時的差異。雖然我們的一百輛車在北京是等間隔的一分鐘一輛出發的，但是它們到達上海時卻并不是按順序一分鐘一輛到達的，甚至可能有晚出發的車比早出發的車先到的情況。互聯網傳輸也一樣，如果簡單地按照收到的音視頻數據順序直接播放出來，就會出現失真的現象。
總結來講：
1. 在網絡上進行實時的音頻交互，編碼后的音頻碼流根據實時傳輸協議組裝成數據包。其中數據包從發送端按照各自的路線經過網絡前往接收端。
2. 全球范圍內，不同區域或者不同時間段，用戶網絡連接的服務質量有時非常差，且不可靠。
基于上述原因，數據包往往不是按準確的順序到達接收端，而是在錯誤的時間以錯誤的順序到達接收端，或數據包丟失等，這就會出現實時傳輸領域通常提到的問題：網絡抖動（jitter），丟包（packet loss），延時（latency）。
丟包、延時、抖動，是基于互聯網進行實時傳輸不可避免的三個問題，不論是在局域網、單一國家地區內傳輸，還是是跨國、跨地區傳輸，都會遇到。
這些網絡問題，在不同區域的分布不同，以聲網Agora 監控的網絡實況來看，在網絡相對較好的中國地區，99% 的音頻互動需要處理丟包、抖動和網絡延時等。這些音頻會話中，20%由于網絡問題會有超過 3% 的丟包，10%的會話有超過 8%的丟包。而在印度的表現差異較大，80%的音頻互動中，大約有 40% 的會話丟失。在印度地區優化 2G/3G 網絡下的服務質量，仍是提供音頻服務的重點。
抖動、延遲、帶寬的限制也是很多的，這些網絡問題導致音頻質量急劇下降，更甚者，影響音頻信號的可懂度，即不能滿足交換信息量的本質通信需求。因此，不論對于使用 WebRTC 的自研團隊，還是提供實時服務的 SDK 服務，嘗試修復這個過程中對音頻信號引入的損傷，都是必修的課題。
丟包控制
為保證可靠的實時互動，處理丟包是必須的。如果沒有提供連續的音頻數據，用戶會聽到卡頓（glitches、gaps），降低了通話質量和用戶體驗。
丟包問題可以抽象為，如何在不可靠傳輸的網絡上，完成可靠傳輸。通常使用前向糾錯 FEC（Forward Error Correction）和 自動重傳請求 ARQ（Automatic Repeat-reQuest）兩個糾錯算法，根據準確的信道狀態估計制定相應策略來解決丟包問題。
FEC 是發送端通過信道編碼和發送冗余信息，接收端檢測丟包，且在不需要重傳的前提下根據冗余信息恢復丟失的大部分數據包。即以更高的信道帶寬作為恢復丟包的開銷。相比ARQ的丟包恢復，FEC 體驗上的延時更小，但由于發送了冗余的數據包，所以信道帶寬消耗較多。
ARQ 使用確認信息 ack（acknowledgements signal，即接收端發回的確認信息表征已正確接收數據包）和 timeouts，即如果發送方在超時前沒有收到確認信息 ack，則通過滑動窗口協議幫助發送端決策是否重傳數據包，直到發送方收到確認信息 ack 或直到超過預先定義的重傳次數。相比 FEC 的丟包恢復，ARQ 延時較大（因為要等待 ack 或不斷重傳），帶寬利用率不高。
簡單講，丟包控制中使用的 FEC、ARQ 方法是通過額外的信道帶寬，以及延時對丟失的數據包進行恢復。這就是傳統抗丟包方法的現狀，那么有什么可行的方法能解決呢？
我們就以之前開源的 Agora SOLO 為例。通常，編解碼器做的事情是壓縮、去冗余，而抗丟包從一定程度上講是信道處理的擴大化。抗丟包是一種糾錯算法的擴展，通過加冗余實現抗丟包。而 Agora SOLO 的策略，是把去冗余和加冗余進行結合，對重點信息加冗余，對非重點信息則更多的去冗余，以達到在信道和信源的聯合編碼的效果。
延時、抖動控制
數據包在網絡傳輸、排隊時本身就會產生延遲、抖動。同時，我們通過丟包控制恢復的數據包也會引入延時和抖動，通常使用自適應的 de-jitter buffer 機制進行對抗，確保音頻等媒體流連續播放。
正如我們上文比喻的，數據包延遲的變化，我們稱之為抖動（jitter），是一條音頻流或其他媒體流數據包之間端到端單向延時的差異。自適應的邏輯是基于數據包到達間隔（IAT，inter-arrival times）的延時估計進行決策。當出現丟包控制未恢復的數據包、過度的抖動、延時、突發丟包，即超出自適應緩存可對抗的延時時，就會出現卡頓。此時接收端一般使用 PLC（Packet Loss Concealment）模塊預測新的音頻數據，以填充音頻數據缺失（由于丟包、過度的抖動和延時引入的丟包、突發丟包）等產生的不連續的音頻信號。
綜上所述，處理網絡損傷，是在不可靠的通信信道上面，通過丟包、延時、抖動控制方法確保數據包盡可能的順序輸出，結合 PLC 預測填充音頻數據的缺失。
要盡可能減小網絡損傷，需要結合以下五點增強弱網邊界：
1. 準確的網絡信道狀態的估計，動態的對丟包控制的策略進行調整和應用；
2. 以及相配套的 de-jitter buffer，以更快、更準的學習速度適應網絡的非穩態（好網絡轉差，差網絡轉好，突發的梳狀網絡）的變化，調整抗抖緩存至大于且更接近于穩態時等價延時的大小，才能確保收聽者在該瞬時網絡環境下的音質好，延時低，逐漸趨于理論最優；
3. 超出弱網可恢復邊界時，通過降低碼率（也常用來解決信道擁塞），提升信道帶寬中冗余數據或重傳次數的開銷；
4. 并結合 PLC 對輸入信號的適應能力，確保不同說話者，時變的背景噪聲下盡可能的減小可察覺的噪聲；
5. 在較小帶寬下，通過編碼器編碼低碼率且高質量的語音，結合3在網絡服務質量差的情況下，增加弱網對抗的魯棒性。
基于以上在丟包、延時、抖動的對抗策略，我們就可以基于互聯網傳輸，提供更好的音頻實時互動體驗。就像我們之前說的，不同地區、不同時間段、不同網絡下，網絡的延時、抖動、丟包情況都不同。而聲網Agora SDK 是面向全球提供高質量的音頻交互服務，讓全球各區域的用戶在線上進行實時互動，通過音頻引擎盡可能將線下的聲學體驗帶給用戶。因此我們也做了多次實地的測試，并觀察 SDK 的 MoS 分（ITU-T P.863）和延時數據表現。
以下是我們在上海中環環線，使用相同設備，在相同運營商網絡下，同時測試的Agora RTC SDK與友商產品的 MOS 分和延時數據。從統計來看，聲網Agora SDK提供的實時音頻交互服務，在提供較高音質的同時，延時更低。
圖：MoS 分對比
圖：延時數據對比
可以從 MoS 分對比圖看出，Agora SDK 的 MOS 主要分布在高分值[4.5, 4.7]區間段，友商主要分布在[3.4, 3.8]。再說一個數據大家可能會有更直觀的概念。我們使用的微信，盡管與 RTC SDK 不屬于同一類型的產品，但也提供語音通話服務。微信在無弱網環境下測量的最高 MoS 分是 4.19。
用戶體驗的實際音頻質量，可由以下音頻質量地圖中圓點的顏色顯示，綠色表示 MOS 分大于4.0；黃色表示 MOS 分處于[3.0, 4.0]，紅色表示[1, 3.0]。
圖：上海中環，Agora SDK 的音頻質量
圖：上海中環，友商 的音頻質量
小結
丟包、延時、抖動是在實時互動場景下不可避免的問題。而且這些問題不僅會由于網絡環境、時段、用戶設備等因素不斷產生變化，也會由于底層技術的發展而產生新的變化（比如 5G 的大規模應用）。所以我們針對它們的優化策略也要不斷迭代優化。
在跟隨音頻信號從發送端經過網絡到達接收端之后，音頻體驗的優化并沒有結束。為了“高音質體驗”，我們還要進一步在端上優化音質，下一篇我們詳細分享其冰山一角，敬請期待。
相關閱讀
