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

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

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

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

　　現(xiàn)在的Cisco WebEx不再是一個簡單的Web Conference產(chǎn)品，它已經(jīng)被定義成一個全新的品牌，相當(dāng)于Cisco的企業(yè)協(xié)作都在WebEx這個品牌之下。在2014年的時候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é)作方案的平臺。在這些產(chǎn)品中，有Teams，Meetings和Calling三款A(yù)PP的產(chǎn)品都已經(jīng)應(yīng)用了最新的Audio engine。

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

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

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

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

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

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

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