視頻會議以其方便、快捷、“面對面”交流的優點逐漸得到了人們的認可,許多企事業單位、教育單位,醫療單位都希望使用視頻會議來代替傳統的會議形式。在視頻會議中,與會者之間主要傳輸的是音頻數據和視頻數據,其中的音頻數據顯得更為重要。因為會議中的大部分有用信息都包含在與會者的言語交上,所以視頻會議系統必須保證音頻通信的流暢性和全雙工,才能使視頻會議更接近于真實的會議環境。
DirectX是Microsoft開發的專門用于開發游戲和多媒體軟件的應用程序接口(API),包括了對二維和三維圖像、聲音、音樂和針對網絡多人游戲的網絡通信的強大支持。DirectX是一種標準的軟件接口,所有主要的硬件供應商都提供支持DirectX的驅動設備,應用DirectX的軟件可以在不同的硬件環境下正常運行。另一方面,DirectX能根據所使用的不同硬件,來選擇適當的方式使用硬件加速能力,便于開發高質量的多媒體和游戲軟件。在DirectX所提供的眾多組件中,用于音頻處理的是Direct Sound組件。為保證視頻會議系統中語音的流暢性,需要采用Direct Sound中提供的Streaming Buffer(流式緩沖)機制來實現。而為了保證視頻會議系統中的全雙工音頻通信,主要利用的則是Direct Sound中的混音機制來實現。
利用Streaming Buffer實現流暢的語音交流
Direct Sound中提供了兩種緩沖機制,分別是Static Buffer(靜態緩沖)和Streaming Buffer(流式緩沖)。Static Buffer指一次將一段完整的聲音存入緩沖中;Streaming Buffer指的是并不將全部的數據一次讀入緩沖,而是在播放聲音時動態地讀入,占用空間較小。一般來說,如果聲音需要反復播放而且容量有限(如游戲音效),使用Static Buffer更有助于提高程序的效率;相反,如果是容量很大、實時性要求較高的音頻數據流,則使用Streaming Buffer為佳。在視頻會議系統中,如使用Static Buffer,則在向緩沖區寫入新的音頻數據時,聲音的回放必然出現短暫停頓,使與會者的完整話語不能夠連續播放,影響通話的流暢性,而Streaming Buffer可克服語音不連續的缺點。
Streaming Buffer提供了兩個指針:Play Cursor(回放游標)和Write Cursor(寫入游標),它們的值只是相對于緩沖區開頭的偏移量而非絕對的內存地址。其中Play Cursor總是指向下一個被輸出的數據字節,而Write Cursor指向的地址則指明從哪個地方開始可以安全地寫入新的音頻數據而不影響回放。按回放音頻數據的順序來看,Write Cursor總是在Play Cursor之前,并且它們間保持著一定的間距,而這個間距會根據不同的系統狀況而有所不同,實驗表明這個間距大概是100~200字節左右。當開始對緩沖區中的音頻數據進行循環模式回放時,總是在Play Cursor所指的地方開始。回放后Play Cursor和Write Cursor會保持它們的間距等速度前移,并且Play Cursor總是指向下一個被輸出的數據字節。當回放到達緩沖區的結尾處時,Play Cursor將重新指向緩沖區的開頭,如此循環下去。而當程序停止對Streaming Buffer中的音頻數據進行回放時,Play Cursor則不再移動,并停留在下一個被輸出的數據字節處,直到重新回放才會繼續前移。另外,在Play Cursor和Write Cursor之間的區域被認為是即將要進行回放的數據,所以不能夠對其做更新。在理解了Streaming Buffer的基本工作方式后,接下來詳細闡述如何用Visual C++作具體實現,其中會涉及到一些Visual C++的函數,具體可參考Microsoft MSDN。
在程序中,設置一個大小為一幀音頻數據的大小(一般相當于0.25秒的語音)的2倍的。并且在正中間和結尾處分別設置標志一個觸發事件。程序開始時,通過調用Play函數對Streaming Buffer中的數據進行循環回放。當Play Cursor到達正中間和結尾時,事件就會產生,就可以通過程序向緩沖區寫入新一幀的音頻數據。在寫入新一幀音頻數據的過程中,首先調用Lock函數鎖定緩沖區中的部分,此時的Write Cursor被鎖定不再前移,而Play Cursor將跟隨著聲音的回放繼續前進;利用回放Play Cursor和Write Cursor間的音頻數據的一段時間內,根據鎖定時獲得的lplpvAudioPtr1(此時lplpvAudioPtr1指向的地方就是鎖定時Write Cursor的所指的地方),lpdwAudioBytes1與Streaming Buffer相關的參數lplpvAudioPtr2、lpdwAudioBytes2等信息,把數據在指定的地方寫入緩沖區,然后調用Unlock函數解除對Write Cursor的鎖定。這樣,Write Cursor重新調整回PlayCursor保持100~200字節間距的地方,繼續對新的音頻數據進行回放。上述這個過程在整個程序的運行過程中,不斷地循環進行,如圖1所示,實現了在對Streaming Buffer中舊一幀音頻數據進行回放的同時寫入新一幀的音頻數據。
從理論上講,這已經保證了音頻回放的流暢性。但在實現過程中,由于操作的對象是一幀的音頻數據,其回放的時間僅是0.25秒,所以必須考慮的一個問題是程序的反應速度問題。如果忽略由事件觸發到真正用Lock函數鎖定緩沖區的部分以進行新數據寫入之間的時間,則這種實現方法沒有任何問題。除了最開始的兩幀數據外,新的一幀數據會緊跟在前一幀數據之后,彼此之間沒有重疊部分,也沒有空隙存在,能很好地達到音頻回放的流暢效果。但事實上,由事件觸發到真正用Lock函數鎖定緩沖區的部分以進行新數據的寫入之間還必須經過線程監聽到事件,分析事件對應的緩沖區,然后再觸發相應的回調函數來進行上面所述的新一幀音頻數據的寫入過程。而這一系列分析工作所占用的時間是會隨系統當時的狀況而變化的,是一個隨機的時間長度,所以每次對緩沖區用Lock函數鎖定緩沖區的部分時,Write Cursor所在的位置都會不同,這樣就造成新的一幀數據并不一定會嚴格地緊跟在前一幀數據之后,它們之間可能會出現重疊部分,也可能會有空隙出現,不利于音頻數據的連續播放。如果出現重疊部分,那么回放造成有部分的音頻數據丟失;如果有空隙的出現,會造成語音的不連續或混亂。但經過調試,仔細分析了由事件觸發到真正用Lock函數鎖定緩沖區的部分以進行新數據寫入之間的時間后,發現它對鎖定時Write Cursor所在位置的偏差產生的波動不大,一般由此產生的重疊部分或空隙部分都在50字節左右,也就是說平均每幀數據中會有50字節的錯誤。在程序中,指定的一幀音頻數據為2000字節(與0.25秒相對應),所以會有大概2.5%的音頻數據會出錯。如果以所采用的音頻格式來計算,8KSPS(采樣率)*8Bit(每個采樣用8位表示)=64KBit/s=8KB/s,那么這2.5%的錯誤在每秒鐘內對應的會是0.025s的音頻數據,基本上人的聽力是難以分辨的。所以在采用Streaming Buffer依然能很好地達到了音頻的流暢性要求。
上面只闡述了音頻回放的實現方法,但作為整個視頻會議系統中的音頻功能來說,還必須有音頻采集部分跟它相配合。音頻采集部分的實現方法與回放模塊的基本原理是一樣,都是利用Streaming Buffer來實現,故此處不再詳述。
利用混音機制實現全雙工音頻通信
Direct Sound中有Primary Buffer(主緩沖區)和Secondary Buffer(輔助緩沖區)兩個緩沖區。前面所述的Streaming Buffer屬于Secondary Buffer。在初始化DirectSound時,它會自動創建一個,這個主緩沖的作用就是進行混音并把混音結果送到輸出設備。除了Primary Buffer外,程序至少還應該創建一個,輔助緩沖的作用是儲存將要使用的聲音,在不使用的時候可以釋放掉,但Primary Buffer是不可釋放的。實現同時播放多個聲音,前提是硬件允許。其工作過程如下,當程序同時對多個Secondary Buffer中的音頻數據進行回放時,Direct Sound會把這些來自于不同Secondary Buffer的聲音在主緩沖區進行自動混音,然后通過輸出設備輸出,如圖2所示。所以通常情況下,用戶并不需要和主緩沖打交道,DirectSound會自行管理。視頻會議系統的全雙工音頻通信功能,就是利用DirectSound的這一混音機制達到的。
視頻會議中要實現的全雙工音頻通信功能并不僅限于兩個與會者之間的全雙工通信,而應該擴展為會議的每個者都能根據需要,同時聽到其他與會者的講話,以達到很好的討論交流效果。為此,在程序中為每個與會者分配一個緩沖數組,數組的大小與一幀音頻數據大小相同。系統開始運行后,程序一方面把各個與會成員的音頻數據幀接收下來,然后根據用戶標識把它們分別保存在相應的緩沖數組中,并按照時間順序排列好,而且會為每個用戶創建一個Streaming Buffer用于音頻回放。另一方面,開始對各個用戶對應內容進行循環播放回放和更新,而更新的音頻數據由各個用戶的緩沖數組順序提供。這樣,不同用戶的音頻信息會自動被Direct Sound進行混音,并把混音的結果放到Primary Buffer中,再從輸出設備輸出,從而達到所需的效果。
提供的Streaming Buffer機制和混音機制,在視頻會議系統中實現了流暢的全雙工音頻通信,使用效果令人滿意。