就在上個週末，我們見證了一場全球共唱的音樂盛事，One World Together at Home。整場活動匯聚了大量的明星大咖，他們通過線上直播的形式，在家裏向全球觀衆獻唱，其中出現了多地藝人同屏獻唱的曲目，但這實際上是錄播的。數百位來自全球各地的演唱者存在現場設備、網絡條件的差異，要實時合唱面臨的技術難點極大。
著名音樂電臺DJ，SoundArio音樂基金會創始人加菲衆就說：
幾百位歌手的時差、現場收錄的和網絡技術條件各不相同，所以並沒有在線實時協作進行直播的可能，甚至兩個人一彈一唱都不可能，因爲0.17秒的延時足以抵消全世界頂級音樂人的現場功力。
這段話中的延時，爲什麼”足以抵消全世界頂級音樂人的現場功力。我們來舉個例子說明一下。以歌曲《稻香》爲例，它的鋼琴曲譜是4/4拍，標準樂曲速度爲80拍/分鐘。副歌部分大約每個音樂小節唱8到12個字，且主要以八分音符和十六分音符組成，基本上每個音符對應歌詞中的一個字。粗略計算的話，大約200 - 300ms左右唱出一個字。
不考慮伴奏的情況下，假設兩個合唱者A和B之間的端到端延時爲100ms。從聲音傳輸流程上來說：
A先唱，B聽到A的歌聲。此時產生100ms延時；
B在聽到A的歌聲後開始加入合唱，歌聲傳到A端。此時又產生100ms延時；
那麼 A聽到B的歌聲永遠延時200ms。根據之前唱每個字所用時間的計算，聽感上會至少慢半個字，是錯位的。
如果要考慮伴奏的傳輸，以及伴奏與歌聲的混音，情況將更加複雜。一般端到端延時只要低於150ms，聽者是感知不到的。所以唱《稻香》這種速度的歌，延時低於80ms可以合唱。如果唱更快速、歌詞更密集的歌，延時要求更低，否則合唱時兩人永遠也對不準拍子，演唱者的體驗也非常糟糕。中國與美國相距1萬多公里，光速爲30萬km/s，光纖傳輸會有一定損耗，可以按照20萬km/s計算，中美之間按15000km物理距離粗略計算，單向延時在75ms左右，無法克服的雙向物理延時就有大約150ms。而且，One World Together中的4人合唱場景，涉及到多方協作，情況更加複雜，所以以目前的技術水平，跨超遠距離的多方合唱是很難做到的。在One World Together中，我們看到的基本都是錄播。不過，不論是錄播還是真的實時合唱，給觀衆帶來最好的體驗纔是最重要的。
在很多社交應用中，都有合唱這一功能，這是如何做到的呢？
01
合唱中的延時
我們首先解讀一下延時是如何產生的。這個場景下的延時包括兩部分：設備端的延時和端到端的延時，我們需要針對不同階段的延時，來分析如何降低延時。
音頻在採集端、播放端的延時
圖：音視頻傳輸流程流程
在這裏，音頻=歌聲，或音頻=歌聲+伴奏。
設備端上的延時包括採集端的採集、前處理、編碼，播放端的接收、解碼、後處理過程產生的延時，以及兩端在編碼後和解碼前產生端網絡延時。
端上的延時主要與硬件性能、採用的編解碼算法、音視頻數據量相關，設備端上的延時可達到 30~200ms，甚至更高。
音頻在設備端上的延時還可以細分爲以下幾點：
音頻採集延時：採集後的音頻首先會經過聲卡進行信號轉換，聲卡本身會產生延時；
音頻播放延時：這部分延時與播放端設備性能相關；
音頻處理延時：前後處理，包括 AEC，ANS，AGC 等前後處理算法都會帶來算法延時，通常這裏的延時就是濾波器階數；
端網絡延時：這部分延時主要出現在解碼之前的 jitter buffer 內。
另外，合唱場景通常會爲用戶提供各種KTV音效，即人聲在編碼傳輸前會增加一步前處理，這還會加大音頻在端上的延時。
若想降低音頻在端上的延時，就需要針對不同機型進行編解碼算法的優化，以降低音頻採集、編解碼、音頻處理帶來的延時。端上延時還與設備性能、系統緊密相關，如果歌手中有一方的設備性能較差，也會影響合唱效果。
端到服務器之間的延時
除了端上的延時，音頻數據在端到服務器、服務器到服務器之間的傳輸過程也會產生較大延時，這也是阻礙“實時合唱”功能落地的重要因素。
影響採集端與服務器、服務器與播放端的延時的有以下幾個因素：客戶端同服務間的物理距離、客戶端和服務器的網絡運營商、終端網絡的網速、負載和網絡類型等。如果服務器就近部署在服務區域、服務器與客戶端的網絡運營商一致時，影響上下行網絡延時的主要因素就是終端網絡的負載和網絡類型。一般來說，無線網絡環境下的傳輸延時波動較大，傳輸延時通常在 10~100ms不定。而有線寬帶網絡下，同城的傳輸延時能較穩定的低至 5ms~10ms。但是在國內有很多中小運營商，以及一些交叉的網絡環境、跨國傳輸，那麼延時會更高。
服務器之間的延時
在此我們要要考慮兩種情況，第一種，兩端都連接着同一個邊緣節點，那麼作爲最優路徑，數據直接通過邊緣節點進行轉發至播放端；第二種，採集端與播放端並不在同一個邊緣節點覆蓋範圍內，那麼數據會經由“靠近”採集端的邊緣節點傳輸至主幹網絡，然後再發送至“靠近”播放端的邊緣節點，但這時服務器之間的傳輸、排隊還會產生延時。
在實時合唱的場景中，要解決網絡不佳、網絡抖動，需要在採集設備端、服務器、播放端增設緩衝策略。一旦觸發緩衝策略就會產生延時。如果卡頓情況多，延時會慢慢積累。要解決卡頓、積累延時，就需要優化整個網絡狀況。
02
合唱也要高音質
唱歌的人都有一個共同的心理需求，就是希望別人誇自己唱得好聽。音質在合唱場景下就顯得尤爲重要了。而影響實時合唱音質的因素主要包括：音頻採樣率、碼率、延時。
採樣率：是每秒從連續信號中提取並組成離散信號的採樣個數。採樣率越高，音頻聽起來越接近真實聲音。
碼率：它是指經過編碼（壓縮）後的音頻數據每秒鐘傳輸所表示的數據量（比特）。碼率越高，意味着每秒採樣的信息量就越大，對這個採樣的描述就越精確，音質越好。
假設網絡狀態穩定不變，那麼採樣率越高、碼率越高，音質就越好，但是相應單個採樣信息量就越大，傳輸時間可能會相對更長。也就是說，高音質也可能會影響延時。
03
敲黑板：解題思路
之前我們提到，因解決方案的不同，“音頻”有着不同的含義，這與你的實現邏輯有關。
1.音頻=歌聲+伴奏
在採集端，我們傳輸的音頻如果是包括歌聲與伴奏。那麼就意味着是這樣的邏輯，如下圖。
歌手A先獲得伴奏；
A 將歌聲與伴奏在本地混音後傳輸給 B；
B 根據A的音頻進行演唱，這時 B 可以聽到合唱的效果；
B 將合唱後的混音傳輸給 A，A 就可以聽到合唱效果了。
在這種傳輸方式下，如果要保證 A 能聽到合唱效果，會有兩段“端到端延時”，即第2、3步產生的。由於B聽到的是A的歌聲與伴奏，所以該方案能保證 B 的體驗。但由於伴奏傳輸給 B，B 的歌聲又需要再傳輸回到 A，A 聽到的伴奏與B的聲音其實之間有很大延時。如果按照上文的延時推斷，你需要付出更多的努力，才能讓端到端的延時降低到歌手A能接受的程度。
2.音頻=歌聲
在這裏，並不是說不要伴奏了。爲了解決伴奏、歌聲之間的延時問題，我們還有一種方法，就是通過雲端將伴奏同時傳輸給A和B，那麼基本可以保證兩者能在同一秒聽到同一個音符。接下來要解決的就只是歌聲的傳輸了。基本實現邏輯如下，也是我們自己的實現方式：
聲網從服務器或本地獲取合唱伴奏；
聲網通過 SD-RTN™ 將伴奏，實時同步發送給歌手 A 和 B；
歌手 A 和 B 會同時聽到伴奏，然後根據伴奏開始自己的演唱；
SD-RTN™ 會實時的將A的歌聲傳給B端，同樣，B 的歌聲也會被實時的傳輸到 A 端；
歌手A和B都能實時聽到伴奏和對方的歌聲；
同時，觀衆可以實時聽到兩個歌手的合唱效果。
這種實現邏輯的好處在於，A、B幾乎同時聽到伴奏，同時演唱，兩者可以實時聽到對方的聲音。要解決的問題就是降低各自歌聲傳輸到對方的這段端到端延時了。相對來講，更加簡單。
除此之外，其實在線下場景中大家可以看到，很多歌手在唱歌的時候通常都會佩戴耳返，那這個耳返的作用效果在線上實時場景中也是非常關鍵：
（1）歌手用來監聽自己的聲音和伴奏，並調節自己音色和情感，這個對延時要求特別高
（2）疊加音效和美聲，歌手能聽到更極致的音效體驗
Agora SDK提供統一接口的低延時K歌耳返功能，通過與手機廠商的深度技術合作，可爲K歌、直播類App提供適配不同手機品牌、不同手機機型的耳返應用，我們將傳統耳返100-300毫秒的延時降低至50ms以內，結合 Agora 音頻整體解決方案，實現超低延時、超低噪聲、極致音效的耳返體驗。
在github獲取我們的合唱Demo，自己動手試試吧????????
https://github.com/AgoraIO-Usecase/Online-Chorus/
