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

　　大家好，我是來自思科的高華，在音頻算法和視頻會(huì)議應(yīng)用開發(fā)方面有10余年經(jīng)驗(yàn)，精通VoIP引擎的設(shè)計(jì)、開發(fā)，擅長麥克風(fēng)陣列、算法性能優(yōu)化等。接下來我將為大家分享的內(nèi)容主要是關(guān)于企業(yè)協(xié)作服務(wù)中的音頻需求。

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

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

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

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

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

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

　　這張ppt是非實(shí)時(shí)處理的介紹。這部分主要包括是Engine State、Statistic model、Metrics、Proximity 和Sound event. Engine State和Statistic model用于VoIP中audio運(yùn)行的健康狀況等統(tǒng)計(jì)。Metrics是整個(gè)Cisco協(xié)作產(chǎn)品中的服務(wù)監(jiān)控?cái)?shù)據(jù)，在會(huì)議結(jié)束后上傳到云端。利用Metrics信息去做大數(shù)據(jù)集，通過大數(shù)據(jù)去管理。然后通過監(jiān)控?cái)?shù)據(jù)監(jiān)測(cè)整個(gè)服務(wù)產(chǎn)品的穩(wěn)定性。目前來說監(jiān)測(cè)的主要方向還是在網(wǎng)絡(luò)和應(yīng)用信息，因?yàn)橥ㄟ^經(jīng)驗(yàn)判斷目前遇到的問題80%以上都是出在網(wǎng)絡(luò)層造成音頻質(zhì)量下降，還有剩下一半以上就是Device、噪聲的等問題。Device的問題是最難解決的一類問題，主要原因是它難以監(jiān)測(cè)。Proximity就是剛才所說的，主要的檢測(cè)TP等視頻設(shè)備來發(fā)送超聲的信息。Sound event是針對(duì)用戶所在的一個(gè)場(chǎng)景，比如說他們?cè)诩抑虚_會(huì)時(shí)有寵物的叫聲，對(duì)這種聲音做一個(gè)檢測(cè)，提示用戶您當(dāng)前的使用場(chǎng)景中有一些噪聲在里邊。

　　剛才提到，在同一個(gè)APP中，會(huì)有多種設(shè)備訪問以及音頻采集的需求。比如，在同一個(gè)APP里面，可能在VoIP call 中，有可能有另外的一個(gè)call 連接進(jìn)來，這時(shí)候就要播ring tone; 或者在播Ringtone過程中，也有可能會(huì)進(jìn)來一條Audio message，需要播放這種Audio message的信息。在此時(shí)就有了一個(gè)新的需求，即在同一個(gè)APP當(dāng)中，不同的應(yīng)用會(huì)訪問不同的底層的AudioDevice，對(duì)不同的AudioDevice去做播放采集的處理。由于在Cisco里，Client team 和 media team不是在同一個(gè)BU，就有可能造成了在client的Design和我們預(yù)期的Design完全不一樣。 因此其中之一的解決方案是學(xué)習(xí)系統(tǒng)層的一個(gè)AudioEngine。 這張ppt是微軟提供的AudioEngine的一個(gè)構(gòu)架圖。我們的應(yīng)用和系統(tǒng)層的AudioEngine是很相像的。對(duì)于系統(tǒng)層的AudioEngine就要支持整個(gè)Application層的多種App，他們會(huì)在同時(shí)訪問到Hardware需求�；�于對(duì)他們的構(gòu)架做的一個(gè)學(xué)習(xí)，提出我們的一個(gè)方案。

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

　　以上就是本次分享的主要內(nèi)容。總結(jié)一下，本次分享中主要介紹了Cisco協(xié)作系統(tǒng)中音頻需求的演化，演化主要是指Audio Engine在Cisco的協(xié)作產(chǎn)品中不同的時(shí)間段，對(duì)不同協(xié)作產(chǎn)品的支持，以及在同一個(gè)協(xié)作產(chǎn)品當(dāng)中像TP、電話或者是multiple call 這樣一種新的應(yīng)用需求的支持。這些需求對(duì)audio的構(gòu)架提出了一些新的挑戰(zhàn)，相應(yīng)的audio engine進(jìn)行的一系列改進(jìn)演化。