基于Internet的語(yǔ)音交互系統的設計和實(shí)現

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



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