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

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



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