基于Internet的語音交互系統(tǒng)的設(shè)計和實現(xiàn)

3系統(tǒng)實現(xiàn)
3．1語音處理
　　語音數(shù)據(jù)處理的整個過程可以分成兩個部分：A／D轉(zhuǎn)換，即把原始聲音的模擬輸入轉(zhuǎn)化為數(shù)字化信息；D／A轉(zhuǎn)換，即把數(shù)字信息轉(zhuǎn)化為模擬數(shù)據(jù)。在通話過程中，跟用戶最直接打交道的是說和聽，所以，語音數(shù)據(jù)處理的好壞直接影響了系統(tǒng)實現(xiàn)的成敗。
　　本系統(tǒng)是要把語音直接轉(zhuǎn)換為數(shù)據(jù)，放在內(nèi)存中，而不是存為語音文件，而且播放語音時，也是直接播放語音數(shù)據(jù)，而不是播放語音文件。這樣的好處是省略了讀寫硬盤的費時操作，提高了語音通話的實時性。要完成上述語音操作，編程語言中提供的容易使用的高級多媒體語音函數(shù)是無法勝任的，只能通過Windows MDK（Multimedia DevelopmentKit）中的多媒體低層音頻服務(wù)來實現(xiàn)，這一類函數(shù)和結(jié)構(gòu)的名字一般都以“wave”作為前綴。Windows下錄制或播放音頻數(shù)據(jù)，其主要操作就是將音頻數(shù)據(jù)讀出到音頻設(shè)備驅(qū)動程序和從音頻設(shè)備驅(qū)動程序?qū)懭氲牟僮鳌５蛯硬ㄐ我纛l函數(shù)通過WAVEHDR結(jié)構(gòu)的音頻數(shù)據(jù)塊對設(shè)備驅(qū)動程序的音頻數(shù)據(jù)進行上述控制。以錄音為例，其準備工作主要有幾點，打開錄音設(shè)備，獲得錄音句柄，指定錄音格式，分配若干用于錄音的內(nèi)存。開始錄音時，先將所有內(nèi)存塊都提供給錄音設(shè)備用來錄音，錄音設(shè)備就會依次將語音數(shù)據(jù)寫入內(nèi)存，當一塊內(nèi)存寫滿，錄音設(shè)備就會發(fā)一個Window消息MM　WIM　DATA給相應(yīng)的窗口，通知程序作相關(guān)的處理，這時程序通常的處理是把內(nèi)存中的數(shù)據(jù)進行復(fù)制，如寫入文件等，在此我們的處理是把數(shù)據(jù)進行壓縮和網(wǎng)絡(luò)發(fā)送，然后把內(nèi)存置空，返還給錄音設(shè)備進行錄音，這樣就形成一個循環(huán)不息的錄音過程。結(jié)束錄音時就釋放所有內(nèi)存塊，關(guān)閉錄音設(shè)備。關(guān)鍵的錄音函數(shù)和順序如下：



　　開發(fā)人員可以充分利用Windows操作系統(tǒng)的多任務(wù)機制，在原始聲音進行采樣的同時對采樣數(shù)據(jù)進行實時的音頻處理，并實時播放處理后的音頻數(shù)據(jù)，使錄音、音頻處理和放音三個原本獨立的過程異步并行處理，以達到原始聲音采樣和處理后的聲音同步播放的實時效果。
　　多媒體低層音頻開發(fā)中，音頻數(shù)據(jù)量一般比較大，應(yīng)用程序必須不斷向設(shè)備驅(qū)動程序提供音頻數(shù)據(jù)塊才能保證錄音或播放的持續(xù)進行。由于錄音和放音的具體操作是由設(shè)備驅(qū)動程序控制音頻硬件在后臺完成的,因而應(yīng)用程序必須檢測什么時候用完一個數(shù)據(jù)塊,并及時傳送下一個數(shù)據(jù)塊，才能避免播放停頓和丟失錄音信息。低層音頻服務(wù)中的回調(diào)機制（Callback Mechanism）為我們提供了檢測音頻數(shù)據(jù)塊使用情況的方法。所謂回調(diào)機制,即在打開音頻設(shè)備時,通過指定設(shè)備打開函數(shù)（waveIn Open（ ）或waveOutOpen（?。┑膄dwOpen參數(shù)來指定一個事件、函數(shù)、線程或窗口作為回調(diào)對象，dwCallback參數(shù)將說明對象句柄或函數(shù)地址。設(shè)備驅(qū)動程序不斷向回調(diào)對象發(fā)送消息，通知音頻數(shù)據(jù)塊的處理狀態(tài)，用戶程序在窗口處理過程或回調(diào)函數(shù)中響應(yīng)這些消息，并做出相應(yīng)的處理。
3．2語音壓縮
　　傳統(tǒng)的電話網(wǎng)是以電路交換的方式傳輸語音的，它需要的基本帶寬為64kbit／s。而要在基于IP的分組網(wǎng)絡(luò)上傳輸語音，就必須對模擬的語音信號進行特殊的處理，使處理后的信號可以適合在面向無連接的分組網(wǎng)絡(luò)上傳輸，這項技術(shù)稱為分組語音技術(shù)。語音壓縮是分組語音系統(tǒng)中的重要組成部分。目前，通過調(diào)制解調(diào)器接入網(wǎng)絡(luò)的最大速率為56kbit／s，遠遠不能適應(yīng)多媒體通信的要求，雖然已有更快的訪問技術(shù)如ISDN，ADSL，但畢竟還不普及。因此必須采用語音壓縮算法來處理語音，而且從節(jié)省網(wǎng)絡(luò)帶寬的角度出發(fā)，語音壓縮也是非常必要的。
　　音頻數(shù)據(jù)是大多數(shù)多媒體應(yīng)用程序向用戶提供信息的主要方式，這些數(shù)據(jù)一般具有較高的采樣速率，如果不經(jīng)過壓縮的話，保存它們需要消耗大量的存貯空間，在網(wǎng)絡(luò)上進行傳輸?shù)男室埠艿?，因此音頻數(shù)字壓縮編碼在多媒體技術(shù)中占有很重要的地位。目前常用的壓縮方法有很多種，不同的方法具有不同的壓縮比和還原音質(zhì)，編碼的格式和算法也各不相同，其中某些壓縮算法相當復(fù)雜，普通程序不可能去實現(xiàn)其編解碼算法。所幸的是，Windows 9x／NT 4．0／Windows 2000為多媒體應(yīng)用程序提供了強大的支持,引入了ACM（Audio CompressionManager,音頻壓縮管理器）,它負責管理系統(tǒng)中所有音頻編解碼器（Coder－Decoder，簡稱CODEC，是實現(xiàn)音頻數(shù)據(jù)編解碼的驅(qū)動程序）,應(yīng)用程序可以通過ACM提供的編程接口調(diào)用這些系統(tǒng)中現(xiàn)成的編解碼器來實現(xiàn)音頻數(shù)據(jù)的壓縮和解壓縮,這一類函數(shù)和結(jié)構(gòu)的名字一般都以“ACM”作為前綴。Windows 9x／NT 4.0／2000系統(tǒng)自帶的音頻COD ECs支持一些音頻數(shù)據(jù)壓縮標準,如MicrosoftADPCM、Microsoft Interactive Multime dia Asso ci ation（I MA）ADPCM、DSP GroupTrueSpeech（TM）等。本系統(tǒng)分別對MSADPCM、IMA ADP CM、MS GSM 6.10 、DSP GroupTrueSpeech（TM）這四種具有代表性的壓縮標準進行了測試和比較。從壓縮率來看，MSA DPCM和IMA ADPCM都是4:1,MSGSM 6．10是2：1,而DSPGroup TrueSpeech（TM）則達到了10：1。從還原后的效果來看，應(yīng)該MSGSM 6．10比較好，而且它支持比較高的采樣頻率，但它的壓縮率太小，我們還是棄用了。而DSPGroup TrueSpeech（TM）有著很高的壓縮率，大大降低了對帶寬的要求，很適合在Internet上傳輸，而且還原后的效果還可以，所以最后還是選用了它。
3．3語音傳輸
　　本系統(tǒng)采用基于Socket的TCP／IP協(xié)議通信，通過在網(wǎng)絡(luò)傳輸層建立兩端計算機的連接來實現(xiàn)實時通信。為了便于在Windows平臺上開發(fā),微軟公司推出了一套以U．C．Berkeley大學(xué)BSD UNIX中流行的Socket接口為范例的網(wǎng)絡(luò)編程接口Windows Sockets。它不僅包含了人們所熟悉的Berkeley Soc ket風格的庫函數(shù)，也包含了一組針對Windows的擴展庫函數(shù)，以使程序員能充分地利用Windows消息驅(qū)動機制進行編程。根據(jù)傳輸數(shù)據(jù)類型的不同，Windows Sockets可分為數(shù)據(jù)流Socket（SOCK　 STREAM）和數(shù)據(jù)報Socket（SOCK—DGRAM）兩類。數(shù)據(jù)流Socket提供了雙向的、有序的的、無差錯、無重復(fù)并且是無記錄邊界的數(shù)據(jù)流服務(wù)，TCP／IP協(xié)議使用該類接口。數(shù)據(jù)報Socket提供雙向的，但不保證是可靠的、有序的、無重復(fù)的數(shù)據(jù)流服務(wù)，也就是說，一個從數(shù)據(jù)報Socket接受信息的進程有可能發(fā)現(xiàn)信息重復(fù)了，或者和發(fā)出的順序不同。
　　根據(jù)以上分析，本系統(tǒng)在實現(xiàn)的過程中采用的是數(shù)據(jù)流Socket，通過在兩臺PC上建立雙向的傳輸連接，可以保證音頻數(shù)據(jù)的實時無差錯傳輸。具體工作是這樣的，首先從CWinThread繼承了兩個子類CSocketListenThread、CMySocketThread。第一個類的工作是一些初始化工作和監(jiān)聽是否有Socket請求連接，這是一個不斷循環(huán)的過程。第二個類的工作是如果有Socket請求來了，那么在這個類里就分配一個Socket給這個請求，從而建立連接。同時在第二個類里還定義幾個輔助函數(shù)，以便事件的觸發(fā)，最典型的是ReadFromSocket（）和SendToSocket（），分別用來接收和發(fā)送，其實現(xiàn)主要是通過Windows底層APIs函數(shù)的調(diào)用。有了這兩個類我們就可以完成Socket的連接、接收和發(fā)送。
　　同時還要指出的是，本系統(tǒng)使用的版本是Windows Socket2，相對Windows Socket1．1來說，Win確良dows Socket2提供了快速、多線程數(shù)據(jù)傳送的能力，性能更加先進，并支持對多種網(wǎng)絡(luò)傳輸方式的一致性訪問和獨立于協(xié)議的多點傳輸／組播，更為重要的是，它提供了在新的網(wǎng)絡(luò)介質(zhì)（ATM、ISD N等）上協(xié)商QoS（Quality of Service）的接口，這樣多媒體應(yīng)用開發(fā)人員可以請求指定傳輸速率，能夠根據(jù)傳輸?shù)耐掏铝拷⒒蛘卟鸪B接，當網(wǎng)絡(luò)暫時不可用時應(yīng)用程序應(yīng)該能自動得到提示?；谝陨峡紤]，我們選擇Windows Socket2來實現(xiàn)對于網(wǎng)絡(luò)數(shù)據(jù)的傳輸，實現(xiàn)過程雖然相對復(fù)雜，但是給系統(tǒng)帶來了良好的性能和擴展性。
4結(jié)束語
　　互聯(lián)網(wǎng)Internet是當今應(yīng)用最廣泛、發(fā)展最迅速的通信網(wǎng)絡(luò)。這是基于數(shù)據(jù)包方式的數(shù)據(jù)分組交換方式，用戶數(shù)據(jù)被封裝在分組中，而分組還包含一些附加信息用于網(wǎng)絡(luò)中的路由選擇、差錯糾正、流量控制等。數(shù)據(jù)包各自獨立地在網(wǎng)絡(luò)中傳遞，由于網(wǎng)絡(luò)狀況的變化和經(jīng)歷路徑的不同，數(shù)據(jù)包到達目的地的時間是不固定的、非實時的，一般來說，互聯(lián)網(wǎng)較適用于數(shù)據(jù)的傳輸，但我們利用了一些現(xiàn)有的技術(shù)，使得音頻信號經(jīng)過模數(shù)轉(zhuǎn)換后也可以作為數(shù)據(jù)在互聯(lián)網(wǎng)上傳遞。由于數(shù)據(jù)網(wǎng)是采用統(tǒng)計時分的方式分配，使用網(wǎng)絡(luò)資源，任何通信實體都不可能獨占某一信道，所以分組語音技術(shù)可以大大提高網(wǎng)絡(luò)資源的利用率。
　　同時應(yīng)該指出的是，當前的VoIP技術(shù)還有一些不足之處，如通話質(zhì)量不高。由于Internet是為數(shù)據(jù)通信目的而設(shè)計的，其通信方式是通過打包傳輸方式實現(xiàn)的，當語音包在一個無服務(wù)質(zhì)量保證的網(wǎng)絡(luò)中傳輸時，會產(chǎn)生包到達順序的錯位，從而產(chǎn)生網(wǎng)絡(luò)抖動，產(chǎn)生語音變形和語音包丟失。所以用IPPhone通話時，斷斷續(xù)續(xù)的現(xiàn)象在當前的技術(shù)下是不可避免的，而且在音質(zhì)、流暢度和時延方面也存在著一定的問題，另外，壓縮技術(shù)也有待改進。雖然當前的壓縮標準有很多，但如何使壓縮率和聲音還原質(zhì)量得到很好的兼顧還有待改善。
　　不過，相信隨著技術(shù)的不斷發(fā)展、網(wǎng)絡(luò)統(tǒng)一化進程的加速進行，數(shù)據(jù)網(wǎng)與電信網(wǎng)之間的結(jié)合勢在必行，CTI（Computer Telephony Integration，計算機電話集成）技術(shù)也越發(fā)會體現(xiàn)出它的價值。