對于泛娛樂領域來講，如何提升用戶活躍、刺激變現是永恒的話題。不僅僅需要運營策劃新活動與玩法，更需要從產品層面不斷提升體驗。

我們曾經分享過“跨直播間PK”的實現思路，這種玩法我們已經可以在幾個主流直播平臺中看到。從實現效果來講，就是不同主播間的粉絲可以同時看到兩個主播在連麥聊天，或做游戲，它的互動性更強。而實現方式有兩種，一種是將多個主播加入同一個直播頻道，然后進行旁路推流；另一種，是利用信令控制來實現，具體請見往期文章。據說在“跨直播間PK”功能上線首日，某個平臺的用戶日活與打賞數據節節攀升，不僅增強用戶粘性，還提升了社交體驗。

“跨直播間PK”是泛娛樂社交平臺對“顏值社交”的深耕與創新場景。但除了“看臉追星”，“聽聲追星”的需求也不容小覷。

人們普遍認為“聲控”只是小眾愛好，僅僅聚集于荔枝、蜻蜓、喜馬拉雅等App上，但其實，如果你留意過抖音、bilibili等平臺，不露臉，只秀音色的視頻或直播同樣能獲得數十萬的關注。圍繞聲音，也有很多值得嘗試的玩法，比如以下幾種。

語音連麥

這是最常見的場景，主播與一個或多個粉絲線上連麥互動。技術實現上比較簡單，幾個用戶之間的音頻數據通過UDP協議進行低延時傳輸，同時利用信令系統來保證用戶進入同一個頻道，并控制通話的開啟、掛斷。

某應用中的語音連麥截圖

主要的挑戰在于保證雙方音頻通話的低延時，一方面是要優化數據傳輸策略，規避網絡擁塞；另一方面，還要做好節點部署，保證大部分用戶的可用性。同時，對于大平臺來講，一旦有大量用戶進行語音連麥，會大幅增加對服務器的請求數，所以還要保證服務端的高可用。

邊聊邊玩

這種模式算是社交與游戲的結合產物，所以我們在一些社交平臺或休閑游戲中能看到。用戶在社交平臺中開啟小游戲，并邀請好友加入，在玩游戲的同時，還能對話、調侃。這個場景的技術難點與語音連麥相近。

邊聊邊唱

這個場景本質上還是語音連麥。不同的是，主播在與用戶聊天的同時，還可以播放本地或云端的音樂伴奏或MV。在所有需要唱歌的場景下，最關鍵，也是最難解決的就是人聲與伴奏的同步。通常在社交直播中，可以通過在主播設備端對人聲與伴奏進行混音，來解決這個問題。

輪麥演唱

我們曾分享的在線KTV就是一個典型的輪麥演唱。主播可以邀請多個聽眾上麥，“話筒”會按順序傳遞給不同連麥觀眾，觀眾自己點歌自己唱。主播仍然可以控制歌曲的播放，如切歌、暫停等操作。其難點主要有兩方面，歌曲控制的同步、高音質與畫質。

某應用中的KTV場景

以上幾種功能，大多比較常見，但還有一種比較少見，也是今天我們要重點解析的，就是實時合唱。

正題來了，什么是實時合唱

現在大部分K歌應用中，都有“合唱”功能。用戶點歌，然后開啟合唱功能，自己一個人根據伴奏演唱，完成后點擊“上傳”，剛才錄下的歌聲就變成了帶有一人歌聲的伴奏。其它用戶可以選擇這個伴奏唱歌，錄制完成后，間接的完成了合唱。簡單來講，就是做了兩次“錄制-上傳”的操作。

這種“錄制合唱”，并不是我們要做的“實時合唱”。

錄制合唱有其優點：音質好，開發者可以設置客戶端錄制和輸出的采樣率、比特率，保證用戶的聲音被原原本本地記錄和傳輸；對網絡要求低，只有在上傳和下載兩個過程需要用到網絡，合唱的混音在本地完成，因此不存在網絡延時問題。合唱的效果也完全取決于用戶自身。其缺憾也顯而易見，就是用戶并沒有“合唱”的體驗，仍然是一個人在唱歌。

而我們要做的“實時合唱”的體驗并非如此。實時合唱的流程體驗大致如下：

發起人點歌，并發起合唱；

邀請好友進行合唱；

合唱伴奏通過網絡同時發送給兩位歌手；

兩位歌手同時在線合唱，并能聽到彼此的聲音。

在實時合唱的場景下，用戶不再是一個人唱，而是在自己演唱的同時，可以聽到好友合唱的聲音。實時合唱能讓用戶像獲得線下一樣的體驗，極大的提升沉浸感。

實現難點是什么？

既然實時合唱更能給用戶帶來參與感，為什么卻不常見呢？與重復“錄制-上傳”的合唱不同，實時合唱的體驗給技術提出了更高的要求，主要包含兩方面。

一、合唱同步

這里的同步指的是兩個歌手的歌聲與伴奏三者之間的同步。我們先假設我們的唱歌的兩位用戶都是專業級的，踩不準節奏的問題完全不存在。如上述場景描述，由于伴奏是同時發送給兩個用戶，那么關鍵就在于兩者的歌聲是否能同步。影響合唱同步的主要因素就是延時。

那么延時會帶來多大的影響呢？為了方便大家理解，我們可以以一個非音樂科班生的角度簡單計算一下。以歌曲《稻香》為例，它的鋼琴曲譜是4/4拍，標準樂曲速度為80拍/分鐘。副歌部分大約每個音樂小節唱8到12個字，且主要以八分音符和十六分音符組成，基本上每個音符對應歌詞中的一個字。粗略計算的話，大約200 - 300ms左右唱出一個字。

不考慮伴奏情況下，人聲的傳輸

不考慮伴奏的情況下，假設上圖中的A和B之間的端到端延時為100ms。從聲音傳輸流程上來說：

A先唱，B聽到A的歌聲。此時產生100ms延時；

B在聽到A的歌聲后開始加入合唱，歌聲傳到A端。此時又產生100ms延時；

那么 A聽到B的歌聲永遠延時200ms。根據之前唱每個字所用時間的計算，聽感上會至少慢半個字，會有錯位感。

如果要考慮伴奏的傳輸，以及伴奏與歌聲的混音，情況將更加復雜。所以，實時合唱場景下的延時越低越好。一般端到端延時只要低于150ms，聽者是感知不到的。所以唱《稻香》這種速度的歌，延時低于80ms可以完美合唱，演唱者的體驗也是好的。如果唱更快速、歌詞更密集的歌，延時要求更低，否則合唱時兩人永遠也對不準拍子，演唱者的體驗也非常糟糕。

那么，如何降低延時呢？這個場景下的延時包括兩部分：設備端的延時和端到端的延時，我們需要針對不同階段的延時，來分析如何降低延時。

歌聲傳輸中要經過的處理過程與延時

音頻在采集端、播放端的延時

這張圖我們曾在《詳解音視頻直播中的低延時》中分享過。設備端上的延時包括采集端的采集、前處理、編碼，播放端的接收、解碼、后處理過程產生的延時，以及兩端在編碼后和解碼前產生端網絡延時。

端上的延時主要與硬件性能、采用的編解碼算法、音視頻數據量相關，設備端上的延時可達到 30~200ms，甚至更高。

音頻在設備端上的延時還可以細分為以下幾點：

音頻采集延時：采集后的音頻首先會經過聲卡進行信號轉換，聲卡本身會產生延時；

• 編解碼延時：隨后音頻進入前處理、編碼的階段，如果采用 OPUS 標準編碼，最低算法延時大約需要 2.5~60ms；
• 音頻播放延時：這部分延時與播放端設備性能相關；
• 音頻處理延時：前后處理，包括 AEC，ANS，AGC 等前后處理算法都會帶來算法延時，通常這里的延時就是濾波器階數；
• 端網絡延時：這部分延時主要出現在解碼之前的 jitter buffer 內。

另外，合唱場景通常會為用戶提供各種KTV音效，即人聲在編碼傳輸前會增加一步前處理，這還會加大音頻在端上的延時。

若想降低音頻在端上的延時，就需要針對不同機型進行編解碼算法的優化，以降低音頻采集、編解碼、音頻處理帶來的延時。端上延時還與設備性能、系統緊密相關，如果歌手中有一方的設備性能較差，也會影響合唱效果。

端到服務器之間的延時

除了端上的延時，音頻數據在端到服務器、服務器到服務器之間的傳輸過程也會產生較大延時，這也是阻礙“實時合唱”功能落地的重要因素。

影響采集端與服務器、服務器與播放端的延時的有以下主幾個因素：客戶端同服務間的物理距離、客戶端和服務器的網絡運營商、終端網絡的網速、負載和網絡類型等。如果服務器就近部署在服務區域、服務器與客戶端的網絡運營商一致時，影響上下行網絡延時的主要因素就是終端網絡的負載和網絡類型。一般來說，無線網絡環境下的傳輸延時波動較大，傳輸延時通常在 10~100ms不定。而有線寬帶網絡下，同城的傳輸延時能較穩定的低至 5ms~10ms。但是在國內有很多中小運營商，以及一些交叉的網絡環境、跨國傳輸，那么延時會更高。

服務器間的延時

在此我們要要考慮兩種情況，第一種，兩端都連接著同一個邊緣節點，那么作為最優路徑，數據直接通過邊緣節點進行轉發至播放端；第二種，采集端與播放端并不在同一個邊緣節點覆蓋范圍內，那么數據會經由“靠近”采集端的邊緣節點傳輸至主干網絡，然后再發送至“靠近”播放端的邊緣節點，但這時服務器之間的傳輸、排隊還會產生延時。

在實時合唱的場景中，要解決網絡不佳、網絡抖動，需要在采集設備端、服務器、播放端增設緩沖策略。一旦觸發緩沖策略就會產生延時。如果卡頓情況多，延時會慢慢積累。要解決卡頓、積累延時，就需要優化整個網絡狀況。

二、高音質

唱歌的人都有一個共同的心理需求，就是希望別人夸自己唱得好聽。音質在合唱場景下就顯得尤為重要了。而影響實時合唱音質的因素主要包括：音頻采樣率、碼率、延時。

• 采樣率：是每秒從連續信號中提取并組成離散信號的采樣個數。采樣率越高，音頻聽起來越接近真實聲音。
• 碼率：它是指經過編碼（壓縮）后的音頻數據每秒鐘傳輸所表示的數據量（比特）。碼率越高，意味著每個采樣的信息量就越大，對這個采樣的描述就越精確，音質越好。

假設網絡狀態穩定不變，那么采樣率越高、碼率越高，音質就越好，但是相應單個采樣信息量就越大，傳輸時間可能會相對更長。也就是說，高音質也可能會影響延時。

敲黑板：解題思路

之前我們提到，因解決方案的不同，“音頻”有這不同的含義，這與你的實現邏輯有關。

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幾乎同時聽到伴奏，同時演唱，兩者可以實時聽到對方的聲音。要解決的問題就是降低各自歌聲傳輸到對方的這段端到端延時了。相對來講，更加簡單。
如上文所說，我們要做的就是優化編解碼算法，并對各個機型進行適配。同時，優化網絡傳輸策略，增加節點部署等。

總結

以上是生活随笔為你收集整理的micropython 实时音频传输_在线实时合唱的实现原理与难点是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。