在LiveVideoStack線上交流分享中，Cisco資深音頻算法工程師高華基于思科的企業協作服務產品實踐，分析整理了協作服務中遇到的音頻需求，詳細介紹了思科WebEx meeting 中的音頻方案——WebEx Media Engine (WME)。

文 / 高華

整理 / LiveVideoStack

直播回放

https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=faac0d5d64b84d4a86fbfd5d4befa468

大家好，我是來自思科的高華，在音頻算法和視頻會議應用開發方面有10余年經驗，精通VoIP引擎的設計、開發，擅長麥克風陣列、算法性能優化等。接下來我將為大家分享的內容主要是關于企業協作服務中的音頻需求。

核心內容分為以下三個部分：

• Cisco WebEx音頻方案發展歷史

• Cisco企業協作中音頻需求的演化

• 音頻引擎介紹

首先從Cisco WebEx音頻方案發展歷史開始。Cisco在2007年的時候收購了一家做Web Conference的SAAS服務公司 —— WebEx 。在2010年之前，WebEx一直使用GIPS作為VoIP引擎，它在2010年的時候被Google收購，開源后就變成了現在的WebRTC。在Google收購GIPS之后，WebEx與GIPS的合同也隨之到期，于是在2010年成立了現在的音頻團隊。音頻團隊成立之初，是以當時GIPS的一些文檔和API為基礎開始制作自己的音頻引擎，到2011年5月份WebRTC實現開源之前，我們已經開始為PC版本的內測以及上線做準備。與WebRTC存在著一個時間差，可以說我們是自行研發出的這款音頻引擎。2012年WebEx的音頻引擎正式上線，然后著手Mobile版本的開發。Mobile版借鑒了WebRTC當中相對成熟的算法模塊AECM。到了2014年，Cisco對于音視頻有了新的規劃，就像WebRTC一樣，將整個Media打包成一個統一的MediaEngine。這個MediaEngine就成為了Cisco未來的一個戰略方向。之后所有Cisco軟件上的需要Media實現的產品都由MediaEngine來做支撐。 以上就是WebEx音頻方案的發展歷史。

在近十年發展過程中需求方所提出的需求也是有比較多的變化。比如像2010年剛成立的時候，主要面對的需求針對的是WebEx。和現在所有的VoIP需求一樣，對于聲音方案的要求是在不同平臺上的采集、3A處理以及Codec，JitterBuffer等。還有一個叫做SVS的應用，是指支持多媒體文件在線共享。由于當時只有一個WebEx的應用，它的所有需求只要做到和VoIP一模一樣就好，并沒有演化出一些應用上更為復雜的需求。但是隨著Cisco協作產品的出現，需求也開始慢慢發生變化。Cisco協作是企業協作平臺，WebEx則是企業協作產品中一個重要的部分，并且在企業協作當中會有更多的其他產品加入。

現在的Cisco WebEx不再是一個簡單的Web Conference產品，它已經被定義成一個全新的品牌，相當于Cisco的企業協作都在WebEx這個品牌之下。在2014年的時候Cisco開始重新做下一代IM和Meeting Cloud的集成應用-Teams；Meetings即最初Cisco的WebEx Web Conference應用；Calling是Cisco收購的一家叫做Broadsoft的公司，提供Cloud Base的PBX應用，解決的是電話服務的問題；Jabber是一種的Cisco的企業IM通信應用；Devices就是包括了Cisco的IPPhone以及TP這樣設備的硬件，基于硬件連接的一些通信服務的設備。Openplatform是向第三方開放并且能夠接入Cisco協作方案的平臺。在這些產品中，有Teams，Meetings和Calling三款APP的產品都已經應用了最新的Audio engine。

因為Cisco有三款APP采用了WebEx Media Engine， 就存在某些用戶同時安裝和運行這三款APP的可能。每一款APP都通過WME（WebEx Media Engine）實現audio的各種功能。這其中就會遇到一些新舊需求的融合問題。例如，在同一個OS上運行著的三個APP，同時在啟用Cisco proximity的需求，它是利用基于超聲通訊進行連接在同一個房間內的TP或者其他的一些桌面視頻設備；與此同時，還有可能在進行VoIP call的需求；以及call 的過程中有multiple-call的需求，即表示和A通話的過程中，B的電話進來了，那么此時你需要先把A掛起，再接入B，也有可能把A和B同時升級到Call conference的需求。 這些需求都是我們音頻解決方案當中需要考慮和解決的問題。這些需求是由于協作產品的擴容以及產品本身多樣性所帶來的需求變化。

接下來介紹WME， WebEx Media Engine，類似于WebRTC中MediaEngine的一個定義。它主要的一些功能，我們列在這里。它主要對Application提供Connection以及SDP協商，超聲接進功能，以及一些聲學事件檢測等功能。聲學事件檢測是在應用過程中有些客戶提出需求，例如說在家中開會（主要是面對的是歐美客戶），他們養的寵物的叫聲，社區里面有一些警報聲，還有像鍵盤敲擊聲之類的噪聲，這些都統一被我們歸類到Soundevent的聲學事件檢測當中；Ringtone它是一個比較泛的類，它的需求除了Call過程中的鈴聲播放，還包括語音信息，DTMF等。MediaTrack這一層更像是WebRtc中MediaEngine，它會把Video，Audio等部分放在一起。對Audio相關的部分提供了Device Manager， Codec管理，還有3A Processing設置，以及對AV synch的支持，以上都被我們放在了WME框架里面。

繼續深入看Audio的這部分方案，這是最新設計的audio Architecture。針對前述的應用需求，主要分為Ringtone，ultrasound 、Sound event，還有VoIP。這張ppt主要介紹的VoIP的實現。我們在audio engine中設計了realtime block和 unrealtime block，中間利用DataInfobus 進行數據共享。realtime的部分是傳統的VoIP這部分，這樣做是源于一個假設，也就是實時VoIP應用是需要盡量減少其他會產生阻塞的操作，如數據處理或者信息統計等。相當于把這些做成了兩個獨立的處理，通過DataBus把實時性處理過程當中可共享的一些數據直接共享給非實時處理。比如像sound event的檢測和ultrasound的檢測，就共享了實時處理的中間結果，運行在其他線程，因為它們可以承受更高的Delay。針對VoIP的需求， 提供了Device的管理；Codec的管理；Transport的管理； Channel的Interface管理，它的管理主要是Process和3A處理參數的設置管理上。這里的Channel和WebRtc的Channel不太一樣，這個Channel是有固定職能的Channel實現?，F在主要分了三種Channel，第一個RecordChannel，就是采集到發送的實現，里面包括AEC和NR，AGC處理。Playback channel是對接收的所有數據處理，包括VoIP和音頻的共享數據流。Broadcastchannel是多媒體文件的音頻發送處理。

這張ppt是非實時處理的介紹。這部分主要包括是Engine State、Statistic model、Metrics、Proximity 和Sound event. Engine State和Statistic model用于VoIP中audio運行的健康狀況等統計。Metrics是整個Cisco協作產品中的服務監控數據，在會議結束后上傳到云端。利用Metrics信息去做大數據集，通過大數據去管理。然后通過監控數據監測整個服務產品的穩定性。目前來說監測的主要方向還是在網絡和應用信息，因為通過經驗判斷目前遇到的問題80%以上都是出在網絡層造成音頻質量下降，還有剩下一半以上就是Device、噪聲的等問題。Device的問題是最難解決的一類問題，主要原因是它難以監測。Proximity就是剛才所說的，主要的檢測TP等視頻設備來發送超聲的信息。Sound event是針對用戶所在的一個場景，比如說他們在家中開會時有寵物的叫聲，對這種聲音做一個檢測，提示用戶您當前的使用場景中有一些噪聲在里邊。

剛才提到，在同一個APP中，會有多種設備訪問以及音頻采集的需求。比如，在同一個APP里面，可能在VoIP call 中，有可能有另外的一個call 連接進來，這時候就要播ring tone; 或者在播Ringtone過程中，也有可能會進來一條Audio message，需要播放這種Audio message的信息。在此時就有了一個新的需求，即在同一個APP當中，不同的應用會訪問不同的底層的AudioDevice，對不同的AudioDevice去做播放采集的處理。由于在Cisco里，Client team 和 media team不是在同一個BU，就有可能造成了在client的Design和我們預期的Design完全不一樣。 因此其中之一的解決方案是學習系統層的一個AudioEngine。 這張ppt是微軟提供的AudioEngine的一個構架圖。我們的應用和系統層的AudioEngine是很相像的。對于系統層的AudioEngine就要支持整個Application層的多種App，他們會在同時訪問到Hardware需求?；趯λ麄兊臉嫾茏龅囊粋€學習，提出我們的一個方案。

這張ppt就是應用層對多device同時訪問需求的解決方案。Session1，Session2，Session3，是在同一個APP中的不同種類的需求。比如Session1，是單純的一個Play需求，它需要的訪問是在DeviceA（Speaker）。Session2 代表UoIP通訊， DeviceB是一個USB device，USB device正被用于VoIP通訊。Session3是超聲檢測，通常會同時對多種設備進行訪問，即同時進行檢測。我們會在不同的Session中構建不同的MediaEngine，在下一層的Audio部分則需要做成統一的Audio Engine，以支撐不同的Session需求，也相當于是做單例實現。接下來就可以通過同一個Audio engine支撐不同的Device訪問。這就是從系統層的實現構架中學習之后構建出的實現方案。

以上就是本次分享的主要內容。總結一下，本次分享中主要介紹了Cisco協作系統中音頻需求的演化，演化主要是指Audio Engine在Cisco的協作產品中不同的時間段，對不同協作產品的支持，以及在同一個協作產品當中像TP、電話或者是multiple call 這樣一種新的應用需求的支持。這些需求對audio的構架提出了一些新的挑戰，相應的audio engine進行的一系列改進演化。

LiveVideoStack? 招募

LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒及技術專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術生態發展。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。

點擊【閱讀原文】，了解更多大會講師及內容信息。

總結

以上是生活随笔為你收集整理的Cisco WebEx：企业协作服务中的音频需求的全部內容，希望文章能夠幫你解決所遇到的問題。

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