遊戲語音解決方案是怎麼煉成的

孟子曰：“獨樂樂，不如與人樂樂；與少樂樂，不若與眾樂樂。”

如果孟子是遊戲發燒友，那麼他肯定說：“單機版不如聯網玩，獨自玩不若遊戲語音開黑玩。”

在棋牌遊戲中，一起打牌的玩家有吹牛嘮叨的社交需求。在MMORPG競技遊戲中，一起並肩作戰的隊友有團隊協同的通訊需求。實時遊戲語音是網路遊戲的標配，這早已經是業界共識。

 現在的問題是，不管是自行研發實時遊戲語音方案,還是採用第三方遊戲實時語音SDK，都必須要先為遊戲量身訂造一套解決方案。這套解決方案必須是和遊戲本身的使用者需求、考量因素、及應用場景緊密結合的。把通用的語音視訊通訊方案直接拿來給遊戲用是不適合的。

今天，我們就一起來深度聊一聊，怎麼針對遊戲的應用場景訂造遊戲實時語音解決方案。

人聲 or 音樂聲

人聲場景是指語音通訊中大部分或者全部時間都是人聲在說話的場景。典型的例子包括Skype網路電話、和微信語音。音樂聲場景是指語音通訊中有相當一部分內容是涉及到音樂和表演等娛樂環節的場景。典型的例子包括花椒直播的連麥K歌海選賽。

遊戲實時語音的場景基本是人聲在說話。現在，讓我們來了解一下人聲語音的特點。人類的聽力感知範圍是從20Hz到20kHz。這個頻寬範圍被劃分成四個頻寬類別：窄帶、寬頻、超寬頻和全帶。

窄帶（narrowband）

普通電話所覆蓋的頻寬，從300Hz到3.4kHz，對應取樣率6.8kHz。普通電話的取樣率是8kHz，對應頻寬4kHz，對於人聲語音是足夠的。

寬頻（wideband）

從50Hz到7kH的頻寬，對應取樣率14khz，可以很好地捕捉和還原人聲，然而對於音樂聲還是不夠的。這是在人聲語音通話場景下的所謂高清語音。

超寬頻（super-wideband）

從50Hz到14kHz，對應取樣率28kHz，基本可以覆蓋人聲和音樂聲，對於非專業音樂人的使用者來說，不管是人聲通話還是音樂直播，這樣的頻寬都是足夠的。

全帶（fullband）

從20Hz到20kHz，對應40kHz取樣率，全面覆蓋人類的聽覺範圍，能夠滿足音樂發燒友或者專業音樂人的需求。超過40Hz都可以稱作全帶語音。CD的取樣率就是44.1kHz。

因此，窄帶(narrowband)的音質是能滿足遊戲實時語音的通訊需求的。考慮到遊戲實時語音和直播結合產生了一些新的玩法，比如說主播陪玩，或者遊戲直播，對音質的要求相對較高。寬頻(wideband)的音質能滿足遊戲加直播場景的需求。在這裡，遊戲語音的頻寬更多地要根據遊戲運營商的預算成本來確定，因為和頻寬直接相關的是位元速率，位元速率最終也就是成本。

考量四大因素

為遊戲量身訂做實時遊戲語音技術方案，要考量四大因素，從中找到平衡點。下圖是對四大因素進行打分（1分最低，5分最高）而建立的雷達圖：

成本

實時遊戲語音資料的流量成本，一般由音訊流的按月峰值頻寬來表示。音訊流的頻寬，由每一路音訊流的位元速率乘以音訊流併發數目而獲得。一路併發音訊流就代表一個活躍的線上使用者。對遊戲運營商來說，音訊流併發數目自然是越大越好。為了控制成本，只能從如何適當地降低每一路音訊流的位元速率來下功夫。目的是在保證其它指標能接受的情況下，音訊流的位元速率越低越好。

延遲時間

人聲語音資訊從一個使用者經過系統和網路傳達另外一個使用者的單向延遲時間。一般來說，150毫秒以內的延遲時間，人耳是識別不了的，實時溝通十分流暢。400毫秒的延遲時間是一個臨界點，超過這個臨界點後，人耳就能感覺到比較明顯的延遲。

筆者在即構科技參與過全球無死角網路覆蓋測試，發現從中國一線城市到矽谷，RTT普遍就在160毫秒以上，單向就在80毫秒以上。 總的延遲時間還要加上編解碼本身的演算法延遲、全鏈條上的計算延遲、和網路損傷帶來的傳輸延遲等。因此，在全球範圍要獲得150毫秒內的延遲是十分具有挑戰性的。畢竟，RTT顯示的單向基本延遲普遍也要80毫秒以上。

 在遊戲實時語音中，保持較低的通話延遲十分關鍵。想象一下，在MOBA或者FPS中，戰鬥正在火熱朝天地進行著，一切都要用“說時遲那時快”來形容，隊友之間的配合協調（比如說加血）慢了一兩秒，帶來的直接後果，輕則是殆誤戰機，重則是全軍覆沒。這是一個視使用者體驗為生命的遊戲平臺所不能忍受的。

音質

從客觀的角度來看，語音的質量由取樣率和位元速率等因素決定。一般來說，取樣率越高音質越好；保持取樣率不變，位元速率越高音質越好。從主觀的角度來看，語音的質量由MOS主觀評估方法來鑑定，也要通過人耳聽感來衡量，畢竟最終是使用者的耳朵來裁定音質好不好。

人耳對人聲的音質的容忍度還是比較高的，而且不同的遊戲和不同的場景對音質也有不同的要求。因此，可以根據不同的遊戲場景來調整音質來讓使用者體驗達到最優效果。在MMORPG、MOBA、和FPS等大型競技類遊戲中，併發數是海量的，總共頻寬相當高。因此，要適當地降低音質，以其降低位元速率來降低成本。在棋牌和狼人殺等節奏比較慢（很多時候沒人說話）且併發相對不高的休閒類遊戲中，要適當地提高音質能提升使用者體驗。

 和音質最緊密相關的因素是成本，其次是延遲和系統影響。一般來說，音質越好，位元速率也會越高，成本也就越高。因此，音質是一個可以微調的因素，用以達到適當的成本平衡點。

 系統影響

實時遊戲語音SDK被遊戲系統進行端到端整合，在客戶端和遊戲系統共用系統資源，包括CPU和記憶體。在移動端，CPU和記憶體資源對遊戲系統來說十分緊缺。因此，實時遊戲語音SDK首先要做到儘量節約CPU和記憶體資源，再進一步的要做到和遊戲和諧共生，那就是在遊戲系統消耗資源比較多的時候，實時遊戲語音SDK要降低位元速率和音質，優先保障語音的可用性；在遊戲系統消耗資源比較少的時候，實時遊戲語音SDK要能提高位元速率和音質，提高通話質量。語音編解碼器的複雜度是影響移動終端CPU、記憶體和電量消耗的一個重要因素，語音編解碼器的複雜度較低的話，消耗CPU、記憶體和電量也就相對少一些。

實時語音的模式

在遊戲協同和溝通中，實時語音通話包括三種模式：

一對一私聊

社交關係比較緊密的兩個遊戲使用者之間的一對一語音通話，通話的音質要高而且延遲要低。

多對多群聊

多個遊戲使用者組隊語音開黑，每一個使用者都參與到群聊中，通話的流暢性要高而且延遲要低。

多人群聊直播

類似多對多群聊，參與群聊的遊戲使用者充當指揮的角色，其它的遊戲使用者充當服從命令的角色，能收聽群聊語音，而不能推送語音。另外，在遊戲直播中，主播直接參與到遊戲語音群聊中，同時把遊戲的實況直播給不參與遊戲的觀眾收聽。在這種模式要求在群聊的少數幾個人之間的通話流暢和低延遲，在觀眾側保障通話的流暢就可以。

 這三種實時遊戲語音通話的模式對上述的四大因素：成本、延遲、音質和系統影響都有不同的側重。除了要匹配這三種實時通話模式，還要匹配四種遊戲語音場景。

遊戲語音的場景

競技遊戲場景

包括MMORPG、MOBA、和FPS等型別的遊戲，遊戲的節奏極快，協同配合要求極高，系統資源也十分緊缺。實時遊戲語音SDK要優先保障流暢性和低延遲，適當允許降低音質。為了滿足這個場景的實時需求，推流和拉流都要經過核心媒體伺服器。

 休閒遊戲場景

包括棋牌和狼人殺等型別的遊戲，遊戲的節奏比較慢，使用者輪流說話，使用者之間短暫的思考時間也是被接受的，系統資源佔用率比較低。實時遊戲語音SDK要優先保障音質和流暢性。在這種場景中，推流和拉流可以不經過核心媒體伺服器，而直接走CDN網路。這種策略比較適合低成本的經濟型方案。

大型國戰場景

包括大型的MMORPG等型別的遊戲，類似於競技遊戲場景。區別在於充當指揮角色的少數幾個人需要進行快節奏的群聊，而其他的遊戲使用者處於收聽狀態。在這種場景中，首先群聊的幾個人的音訊流要經過核心媒體伺服器，然後多路音訊流被混和成一路流，接著轉推到CDN網路，最後收聽模式的遊戲使用者從CDN網路拉流收聽。

選取音訊編解碼器

音訊編解碼器對遊戲實時語音方案的四大關鍵因素有重要的影響。音訊編碼器的型別、屬性和品質，決定了編出來的音訊流的位元速率、演算法延遲、頻寬、和音質；音訊編碼器的演算法複雜度決定了對CPU、記憶體、和電量的消耗程度。

 因此，適合遊戲實時語音方案的音訊編解碼器具備以下四個特點：

1）位元速率相對低，滿足成本可控的要求，一般不要超過16kbps。一個sample用1bit就能編好，那麼8kHz取樣率（narrowband）對應8kbps的位元速率，16kHz取樣率（wideband）對應16kbps的位元速率。位元速率的本質就是成本。

2）延遲時間要低到能滿足互動需求，一般不要超過300毫秒。

3）演算法複雜度要比較低，對系統CPU、記憶體和電量消耗少，對遊戲系統影響要儘量低。

4）音質可以適當作出犧牲，以保障上面三個因素，8kHz取樣率對人聲場景是夠用的，16kHz取樣率可以提供高清語音。

下圖列舉一組主流的音訊編解碼器，展示了隨著位元速率變化，音質相應變化的情況。這是基於編解碼器聽音測試的結果繪畫出來的，對選取音訊編解碼器有參考意義。根據上面的分析並且參照下圖，發現位元速率低於16kbps的低位元速率人聲編解碼器（speech codecs）包含：Opus（SILK）,Speex，AMR-NB，AMR-WB，和iLBC。

下圖是另外一組主流的音訊編解碼器，展示了隨著位元速率的變化，演算法延遲時間相應變化的情況。根據上面的分析並且參照下圖，發現演算法延遲時間低於60毫秒，位元速率低於16kbps的人聲編解碼器（speech codecs）包含：Opus（SILK）、Speex(NB,WB)、G.729、和G.729.1。

綜合上面的兩個圖，我們可以大致總結，比較適合實時遊戲語音的音訊編解碼器包含Opus（SILK）、Speex（NB,WB）、AMR-NB、AMR-WB、iLBC、G.729、和G.729.1。

上面都是為人聲場景設計的低位元速率音訊編解碼器，具有位元速率低（16kbps以下），演算法延遲低（大部分在40ms以下），和取樣率在8kHz和16kHz之間的特點，都可供遊戲實時語音方案選擇。其中，有幾個語音編解碼器值得在這裡稍作介紹：

 Opus（SILK）

完全開源而且免費，包含了SILK、CELT、以及兩者的混合模式，是目前最為相容幷包的音訊編解碼器。在處理窄帶和寬頻人聲語音（speech）的時候，採用SILK; 在處理超寬頻和全帶音樂聲音（music）的時候，採用CELT。在人聲和音樂聲混合的場景中，甚至可以智慧切換兩個編解碼器。WebRTC就採用了Opus作為語音編解碼器。而SILK是Skype網路電話所用的語音編解碼器。Opus真可謂是久經考驗的名門精品。根據即構科技的測試結果，Opus雖然在音樂場景中表現並非首選，但是在人聲場景中表現十分出色。

 iLBC

完全開源而且免費的，由GIPS開發並被IETF標準化，曾經被QQ和Skype使用過，現在被WebRTC使用，是被世界頂級產品證明過的窄帶實時語音編解碼器。iLBC能夠通過平滑降低語音質量的方式來處理IP網路丟包。由於iLBC的語音幀塊之間是相互獨立的，在丟幀出現的時候也不會導致錯誤蔓延，因此具有較強的抗丟包能力。在窄帶應用環境中，iLBC具有延遲低，無斷續或雜音的特點，通話效果可以和行動電話媲美。

Speex

免費的人聲音訊編解碼器。因為Speex是為VoIP專門設計的，所以Speex對IP網路有很強的抗丟包能力。為了達到這個目的，Speex採用了CELP演算法。筆者在上一週仔細研究了市場上狼人殺產品的遊戲實時語音技術，就發現有廠商自研的方案採用了Speex。

Codec2

開源並且專利免費，位元速率超低的人聲語音編解碼器。位元速率在0.7 kbps至3.2 kbps。Codec2填補了開源編碼器在5 kbps位元速率以下的空白。如果你覺得上面的語音編解碼器位元速率都不夠低，建議嘗試一下Codec2。

 在評估一個音訊編解碼器是否適合用於具體的遊戲實時語音方案的時候，除了要評估上述的指標：位元速率、取樣率、和演算法延遲以外，還要參考MOS、VBR/CBR、和基礎演算法等。其中，MOS （Mean Opinion Score）是語音編解碼器的主觀評估指標。MOS是一個廣為接受的有統計意義的主觀聽音指標。上面音視訊編解碼器的列表沒有把它包含進去，是因為同一個編解碼器，在不同位元速率下，表現出來的MOS值是會變化的。對一個音訊編解碼器給出一個固定的MOS值，反而會起誤導的作用。另外，雖然MOS值已經是主觀的聽覺測試評估結果，但是音訊工程師在選用音訊編解碼器的時候，還要以自己親身的聽感作為最終的依據。

 下圖是Nokia在2011年的時候對Opus、AMR、和G.722.1C等音訊編解碼器在無噪音和有噪音的環境裡做的MOS語音測試的結果。我們可以從語音測試的結果看出：

1）MOS值會隨著位元速率變化。固定的MOS值並沒有絕對的參考意義。

2）在低位元速率情況下，AMR-NB和AMR-WB都表現相對出色。

沒有任何一個音訊編解碼器可以適合任何應用場景。每一個音訊編解碼器都有自己的優勢和劣勢，都有適合它發揮作用的應用場景。在為遊戲實時語音方案選取語音編解碼器的時候，首先要梳理清楚該遊戲場景的需求，然後根據需求去選取音訊編解碼器。

 讓我們回顧一下前面討論過的遊戲場景，分析如何針對遊戲場景選取合適的語音編解碼器。

競技遊戲場景

包括MMORPG、MOBA、和FPS等型別的遊戲，遊戲中組隊的使用者需要每時每刻十分高頻地通話以協同作戰，而且這種型別的遊戲佔用系統和網路資源很多。這種場景對遊戲實時語音SDK的要求是位元速率低、延遲低、和消耗低，音質只要能保障溝通無阻就可以。因此，選取的音訊編解碼器要具備這些特點：位元速率低、演算法延遲低、以及演算法複雜度低。在這個前提下，再選取取樣率較高和MOS值較高的音訊編解碼器。上述提到的Codec2、Speex、和AMR-NB都比較適合競技遊戲場景，建議對它們進行進一步測試對比。

 有些休閒遊戲的溝通節奏也相當快，比如說馬東的米未傳媒最近推出的飯局狼人殺，在殺人遊戲環節允許使用者插麥（插話），打破了傳統狼人殺輪流發言而不允許插話的規則。在這種情況下，飯局狼人殺雖然是休閒遊戲場景，但是也應該當做競技遊戲場景來處理。從技術的角度來說，選取的語音編解碼器就要優先保障低延遲和流暢性，然後再考慮音質；另外，推拉流都要經過核心媒體伺服器，以此獲得比較低的延遲，插麥的效果才能保障。如果推流直接推送到CDN網路，插麥的延遲將會達到至少1到3秒，插話的體驗就會無法接受。

休閒遊戲場景

包括棋牌和狼人殺等型別的遊戲，遊戲中的使用者交流的節奏不快，允許一到兩秒的思考時間，而且這些遊戲佔用系統和網路資源也不多。這種遊戲場景的社交屬性比較強，社交關係好的遊戲使用者甚至會進行一對一私聊。休閒遊戲場景對實時遊戲語音SDK的要求是音質比較好、位元速率比較高；而延遲允許高一點，系統消耗也允許多一點。因此，選取的音訊編解碼器就要具備這些特點：取樣率較高、位元速率較高、以及MOS值較高；在這個前提下，再選取演算法延遲較低，和演算法複雜度較低的音訊編解碼器。上述提到的Opus（SILK）、AMR-WB、Speex、和iLBC都比較適合休閒遊戲場景，建議對它們進行進一步測試對比。

最近半年，休閒遊戲的遊戲實時語音技術出現了一些新的玩法：有些遊戲平臺在遊戲實時語音中增加了實時視訊。使用者可以有選擇性地在遊戲實時視訊中露臉，遊戲平臺也通過一些機制去鼓勵使用者多在視訊中露臉。比如說奇虎360最近推出的萌萌狼人殺，又名花椒狼人殺（和花椒直播同樣是奇虎360的產品），就在遊戲使用者輪到發言的時候，允許選擇是否全屏展示視訊。由於萌萌狼人殺採用了即構科技的遊戲實時音視訊方案，因此筆者比較清楚此類方案的技術細節。從技術的角度來說，增加了視訊，必然會增加位元速率（頻寬的開銷）。在弱網的情況下，丟包率會驟然增加，音視訊的質量也會相應下降，這時候要優先保障語音通話。具體地說，要優先保障語音的低延遲和流暢性，視訊和音質可以稍微妥協。因此，在選用音訊編解碼器的時候，就要優先考慮位元速率低和延遲低的，甚至可以選用一套位元速率低的和一套取樣率高的結合著使用，用以適應不同的應用場景和網路條件。

 大型國戰場景

包括大型的MMORPG等型別的遊戲，充當指揮角色的一組遊戲使用者的網路溝通節奏其實和競技遊戲場景是類似的，選取音訊編解碼器的原則也類似。除了Codec2、Speex、和AMR-NB以外，其實Opus（SILK）的覆蓋面很廣，建議也測試對比一下。

經過幾輪測試和對比下來，你很可能會發現，要結合使用一兩個編解碼器才能很好地滿足某個遊戲場景的需求。最終，我們要做的是尋找位元速率、延遲、複雜度、取樣率、和MOS值這幾個關鍵指標的平衡點。畢竟這幾個指標和我們最開始討論的四大要素：成本、延遲時間、系統影響、以及音質是緊密相關的。

 要針對具體的遊戲場景訂造特定的解決方案，沒有任何一套方案是放諸四海皆準的。要為具體的方案去配置特定的音視編解碼器，和推流、拉流、以及混流策略。甚至有些時候，在同一套遊戲實時語音解決方案中，要採用多個的音訊編解碼器來適應不同的業務場景或者網路狀況的需求。

結語

因此，做遊戲實時語音解決方案就是在遊戲應用場景和技術方法之間做匹配。只有深入地理解遊戲應用場景的需求，才能拿捏好如何選用語音編解碼器，如何部署媒體伺服器資源，如何配置CDN網路等，來打磨出一套符合遊戲應用場景需求的實時語音解決方案。