【正文】 流的聲卡驅(qū)動程序集：OSS/Lite（也稱為OSS/Free）、OSS/Full（商業(yè)軟件）、ALSA（自由軟件）。出于對安全性方面的考慮，Linux下的應用程序無法直接對聲卡這類硬件設備進行操作，而是必須通過內(nèi)核提供的驅(qū)動程序才能完成。 （3）.聲道數(shù)聲道數(shù)是反映音頻數(shù)字化質(zhì)量的另一個重要因素，它有單聲道和雙聲道之分。常用的采樣位數(shù)有8位、12位和16位。8位代表2的8次方256，16 位則代表2的16次方64K。采集卡的位是指采集卡在采集和 播放聲音文件時所使用數(shù)字聲音信號的二進制位數(shù)。所以在電腦上錄音的本質(zhì)就是把模擬聲音信號轉(zhuǎn)換成數(shù)字信號。這個數(shù)值越大，解析度就越高，錄制和回放的聲音就越真實。常用的音頻采樣頻率有8kHz、16kHz、48kHz等，如果采用更高的采樣頻率，還可以達到DVD的音質(zhì)。采樣頻率的選擇應該遵循奈奎斯特（Harry Nyquist）采樣理論：如果對某一模擬信號進行采樣，則采樣后可還原的最高信號頻率只有采樣頻率的一半，或者說只要采樣頻率高于輸入信號最高頻率的兩倍，就能從采樣信號系列重構原始信號。采樣就是每隔一定時間就讀一次聲音信號的幅度，而量化則是將采樣得到的聲音信號幅度轉(zhuǎn)換為數(shù)字值，從本質(zhì)上講，采樣是時間上的數(shù)字化，而量化則是幅度上的數(shù)字化。對于采樣過程中的每一個樣本來說，數(shù)字音頻系統(tǒng)會分配一定存儲位來記錄聲波的振幅，一般稱之為采樣分辯率或者采樣精度，采樣精度越高，聲音還原時就會越細膩。數(shù)字音頻系統(tǒng)通過將聲波的波型轉(zhuǎn)換成一系列二進制數(shù)據(jù)，來實現(xiàn)對原始聲音的現(xiàn)，實現(xiàn)這一步驟的設備常被稱為模/數(shù)轉(zhuǎn)換器（A/D）。接收方則對網(wǎng)絡層傳來的數(shù)據(jù)包解封，并交由RTP提取音頻數(shù)據(jù)，然后進行音頻解壓縮，再經(jīng)揚聲器播放出來。采用在計算機以太網(wǎng)上進行點對點的通信模式。目前Linux已經(jīng)得到了越來越多的應用。Linux是一位芬蘭的年輕人Linus Benedict Torvalds于1991年10月在赫爾辛基大學對外正式發(fā)布一套操作系統(tǒng)，它一種Unix風格的操作系統(tǒng)，在源代碼級上兼容絕大部分Unix標準，是一個支持多用戶、多進程、多線程、功能強大而且執(zhí)行穩(wěn)定的操作系統(tǒng)。第三章 實時語音通信系統(tǒng)簡介 系統(tǒng)平臺本系統(tǒng)是在linux下實現(xiàn)的，選用Ubuntu ，vim作為編寫工具，編程語言采用C++。 RTP數(shù)據(jù)包格式2．3．1 RTP數(shù)據(jù)包格式RTP報文頭格式（見RFC3550 Page12）： 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +++++++++++++++++++++++++++++++++ |V=2|P|X| CC |M| PT | sequence number | +++++++++++++++++++++++++++++++++ | timestamp | +++++++++++++++++++++++++++++++++ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +++++++++++++++++++++++++++++++++以上域具體意義如下： （1）版本(V):2比特 .(值1被RTP草案版本使用,值0用在最初vat語音工具使用的協(xié)議中.) （2）填料(P):1比特 若填料比特被設置,此包包含一到多個附加在末端的填充比特,或者在底層數(shù)據(jù)單元中傳輸多個RTP包. （3）擴展(X):1比特 若設置擴展比特,固定頭(僅)后面跟隨一個頭擴展. （4）CSRC計數(shù)(CC):4比特 CSRC計數(shù)包含了跟在固定頭后面CSRC識別符的數(shù)目. （5）標志(M):1比特 ,. （6）負載類型(PT):7比特 此域定義了負載的格式,。比如視頻混合器，它可以將多路不同的視頻流的單個圖像混合成一路視頻流，模擬一個群體場景。在防火墻內(nèi)外各安裝一個轉(zhuǎn)換器，當外面的轉(zhuǎn)換器接收到安全的數(shù)據(jù)包后，將它們以隧道方式直接發(fā)送給防火墻內(nèi)的轉(zhuǎn)換器，由它轉(zhuǎn)發(fā)給防火墻內(nèi)的用戶。RTP包頭提供了一個字段CSRC，使混合器可以辨別混合報文的各個信源，這樣在接收端就可以正確獲知誰是發(fā)送者。混合器（Mixer）是一個RTP層的中繼設備，將它置于低速鏈路端，它對到來的音頻報文按20毫秒的間隔重新進行同步，然后將重構的音頻數(shù)據(jù)流混合成一路窄帶的數(shù)據(jù)流轉(zhuǎn)發(fā)給窄帶用戶。盡管采用獨立的RTP會話，同源的音頻和視頻可以根據(jù)RTCP的時間信息進行同步回放。在RTP層音頻和視頻并沒有直接的聯(lián)系，除非某個特定的用戶需要在RTCP報文中使用相同的標識將這兩個RTP會話聯(lián)系起來。一個與會者離開會議時要發(fā)送RTCP BYE報文，以通知其它的參與者自己離開了。RTCP接收報告表明了這一與會者接收語音數(shù)據(jù)的效果，同時它可以用來控制自適應編碼器。與會者在會議進行期間可能加入或退出，因此了解在某一時刻有哪些人參加了會議，以及它們的語音數(shù)據(jù)接收情況是很有必要的。其計時信息是接收方按照會議中不同的RTP源分別重建的。Ineternet和其他報文網(wǎng)絡一樣，會有丟包，報文失序以及報文的不同時延問題。當一個與會者將要發(fā)言時，其話音將以每20毫秒為一幀的間隔分成許多音頻數(shù)據(jù)包，并在數(shù)據(jù)包前加上RTP頭，然后按照RTP包頭在前，數(shù)據(jù)在后的順序?qū)⑺鼈兎庋b在UDP包中。一個端口用于RTP傳輸音頻數(shù)據(jù)，另一個端口用于傳輸RTCP控制包。 RTP與各種網(wǎng)絡協(xié)議的關系 RTP協(xié)議的三類主要應用（1）簡單的多播音頻會議這里的多播主要指IP網(wǎng)絡的多播業(yè)務用于語音通信。如果底層網(wǎng)絡支持多點傳播的話，RTP還支持使用多點傳播向多個目的端點發(fā)送數(shù)據(jù)。當然，RTP還可以和其他合適的底層網(wǎng)絡和傳輸協(xié)議一起工作。再次，由于UDP的傳輸時延低于TCP，能與音頻和視頻流很好匹配，保證了實時性的要求。首先RTP可以利用UDP的多路復用功能來分別傳輸RTP數(shù)據(jù)包和RTCP控制包。一般來說，RTP是在傳輸層協(xié)議之上作為應用程序的一部分加以實現(xiàn)的。它不是典型意義上的傳輸層協(xié)議，因為它并不具備一個典型傳輸協(xié)議的所有特點。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，所以特別適合傳輸實時數(shù)據(jù)。RTP協(xié)議包括RTP（Realtime Transport Protocol）實時傳輸協(xié)議和RTCP（Realtime Transport Control Protocol）實時傳輸控制協(xié)議這兩個協(xié)議。它是IETF提出的一個標準，對應的RFC文檔為RFC3550（RFC1889為其過期版本）。RTCP（Realtime Transport Control Protocol）實時傳輸控制協(xié)議，它提供服務質(zhì)量的統(tǒng)計信息及提供傳輸可靠性的保證和流量的擁塞控制機制。音頻和視頻編碼信數(shù)據(jù)均封裝在RTP協(xié)議數(shù)據(jù)包中，RTP提供定時信息和數(shù)據(jù)報序號，供接收方重組數(shù)據(jù)包，但是RTP本省并不能為按順序傳送數(shù)據(jù)包提供可靠的傳輸機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。同時如果收發(fā)端能夠?qū)崟r了解網(wǎng)絡和傳輸狀況，就可以適當調(diào)節(jié)自己的任務，最終使得在接收端能夠達到最好的效果，由此引入RTCP傳輸控制協(xié)議對傳輸狀況進行實時監(jiān)測和報告。所以本文在IP網(wǎng)絡上建立的實時音頻傳輸系統(tǒng)采用面向無連接的UDP協(xié)議進行傳輸。它取消了重發(fā)校驗機制，因此能夠達到較高的通信速率，但不能保證報文的先后順序，也不能保證數(shù)據(jù)傳輸?shù)目煽啃浴?RTP的引入基于上一節(jié)的分析，我們可以清楚的認識到TCP協(xié)議是不適合用來進行傳輸實時多媒體數(shù)據(jù)的，因此考慮選擇UDP作為RTP的傳輸層協(xié)議。（4）.報文頭的大小TCP和XTP報文頭都比UDP的報文頭大，而RTP的固定報文頭為12字節(jié)，因而它們所能攜帶的信息占整個報文的比例相對來說比較小。另一方面，音頻、視頻在特定的編碼方式下，產(chǎn)生的編碼數(shù)量是不可能突然改變的，例如，標準的PCM音頻需要64Kb/s，加上一些額外控制信息，它不能再低于這個帶寬要求的網(wǎng)絡上傳輸。這一過程將需要一個甚至更多的周期，這種重傳機制對于實時性要求較高的多媒體數(shù)據(jù)傳輸來說是災難性的，因為接收不得不等待重傳數(shù)據(jù)的到來，從而造成了延時和斷點。而在一個實時多媒體的應用中，我們期望盡量少的延遲。下面具體分析網(wǎng)絡運行一下TCP和其他可靠傳輸層協(xié)議如XTP不適合實時傳輸?shù)膸讉€主要原因。但是在大多數(shù)情況下，我們需要再廣域網(wǎng)內(nèi)傳輸數(shù)據(jù)，在這種丟包率較高、網(wǎng)絡狀況不好的情況下，利用TCP協(xié)議進行視頻或音頻通信顯然不是很好的一個選擇。當然在傳輸用于回放的視頻和音頻數(shù)據(jù)時，TCP也是一種選擇。為保證數(shù)