【正文】 傳輸層協(xié)議。而在一個實(shí)時多媒體的應(yīng)用中，我們期望盡量少的延遲。為保證數(shù)據(jù)的可靠傳輸，在傳輸層使用 TCP 協(xié)議，當(dāng)接收端檢測到數(shù)據(jù)包丟失或錯誤時，要求發(fā)送端重新發(fā)送，但這 樣不可避免地引起傳輸延時和占用網(wǎng)絡(luò)帶寬。北京的微軟亞洲研究院的網(wǎng)絡(luò)多媒體組正在做 SMART 音 /視頻傳輸(SMART A/V Delivery)等項。 1992 年 3月， IETF（ Inter Engineering Task Force）在 San Diego 召開的會議是分組網(wǎng)上第一次大規(guī)模的音頻多播應(yīng)用。 第六章：介紹了音頻解碼和編碼的實(shí)現(xiàn)。例如，一個多媒體會議系統(tǒng)，我們總是希望發(fā)言者的發(fā)言能夠盡早讓收聽者收聽到，也就是說時延盡量短；另外一個就是我們希望在收聽者收聽語音信息時，一句話平滑的，即中間沒有斷點(diǎn)，也就是等時性。 系統(tǒng)建設(shè)原則 ................................... 錯誤 !未定義書簽。 平臺的搭建與優(yōu)點(diǎn) ............................... 錯誤 !未定義書簽。 技術(shù)平臺的介紹 ................................... 錯誤 !未定義書簽。 存在不足的分析 ................................. 錯 誤 !未定義書簽。 系統(tǒng)開發(fā)計劃 ................................... 錯誤 !未定義書簽。 本文結(jié)合 RTP/RTCP 高實(shí)時性的特點(diǎn)，主要針對局域網(wǎng)，提出了音頻數(shù)據(jù)采用G729a 壓縮，傳輸數(shù)據(jù)采用 ortp 庫，在 linux 平臺下開發(fā)的實(shí)時語音通信系統(tǒng)。但是， Inter 是建立在 TCP/IP 之上的計算機(jī)網(wǎng)絡(luò)，最初設(shè)計時的定位決定了它不適合實(shí)時數(shù)據(jù)的傳輸。 術(shù)語定義 ....................................... 錯誤 !未定義書簽。 國內(nèi)外網(wǎng)絡(luò)教學(xué)研究發(fā)展?fàn)顩r和分析 .................................. 3 網(wǎng)絡(luò)教學(xué)的發(fā)展 [5] ................................ 錯誤 !未定義書簽。 B/S 結(jié)構(gòu)的特點(diǎn) ................................. 錯誤 !未定義書簽。 ADO 技術(shù) [12] ..................................... 錯誤 !未定義書簽。 使用可行性 ..................................... 錯誤 !未定義書簽。 系統(tǒng)數(shù)據(jù)描述 ................................... 錯誤 !未定義書簽。 第三章：介紹了 linux 下基于 RTP 的實(shí)時語音通信系統(tǒng)實(shí)現(xiàn)的基本原理和總體架構(gòu)。 IPv6解決了 IPv4 地址資源有限，不能控制帶寬等問題， RSVP(資源預(yù)留協(xié)議 )， RTP/RTCP（實(shí)時傳輸 /控制協(xié)議）使 Inter 從理論上具備了處理實(shí)時 業(yè)務(wù)的能力，解決了媒體同步問題和滿足多媒體通信業(yè)務(wù)的要求。 在國內(nèi)，清華電子工程系網(wǎng)絡(luò)研究所多媒體通信課題組也在這方面做了大量的研究，并開發(fā)出了 Coolaudio、 CoolVideo、 CoolMeeting 等一系列軟件。這些都是實(shí)現(xiàn)實(shí)時語音通話應(yīng)達(dá)到的要求。 TCP 協(xié)議是面向連接的協(xié)議，它的重傳機(jī)制和擁塞控制機(jī)制都是不適合用于實(shí)時多媒體傳輸?shù)摹Ｕ_的擁塞控制應(yīng)該是變換音頻、視頻信息的編碼方式，調(diào)節(jié)視頻信息的幀頻或者圖像的大小。但是 UDP 傳輸?shù)牟豢煽繋韥G包、亂序等問題，所以如果在應(yīng)用層采用合適的封裝方式并增加一些有利于媒體播放的信息進(jìn)行傳輸，可以使得接收端在一定程度上彌補(bǔ)傳輸帶來的損失，這就是引入 RTP的原因。 RFC3550 不僅定義了 RTP，而且定義了配套的相關(guān)協(xié)議 RTCP（ Realtime Transport Control Protocol，即實(shí)時傳輸控制協(xié)議）。 在 IP網(wǎng)絡(luò)上， RTP 協(xié)議一般是運(yùn)行在 UDP 之上。下圖表示了RTP 與各種網(wǎng)絡(luò)協(xié)議的關(guān)系。為嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 7 了克服這些不利因素， RTP 包頭攜帶時間戳和序列號，這樣接收方就可以重建源產(chǎn)生的計時信息，語音報文可以按照 20 毫秒的間隔連續(xù)回放了。 （ 2）音頻和視頻會議 如果在一個會議里同時有音頻和視頻，它們將采用獨(dú)立的 RTP 會話來傳送，兩個媒體流的 RTCP 報文采用不同的 UDP 端口對或多播地 址。 “轉(zhuǎn)換器”（ Translators）也是一種 RTP 層的中繼設(shè)備，當(dāng)某些與會者不能通過多播（ multicast）方式直接連接到會與，比如它們處在不讓任何 IP 包通過的應(yīng)用級防火墻之后，這時就需要用到“轉(zhuǎn)換器” 。在 linux 平臺上，音頻采集采用 ALSA（ Advanced Linux Sound Architecture ）的 lib 庫，利用網(wǎng)上現(xiàn)有的 oRTP 庫實(shí)現(xiàn)基于 RTP 的實(shí)時語音傳輸。 下面圖 ： 實(shí)時語音通信模塊實(shí)現(xiàn)過程 見下圖 ： 圖 基本框架流程圖 本系統(tǒng)核心模塊是語音通話模塊的實(shí)現(xiàn)，下面是語音通話模塊的流程圖： 嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 12 語音通話模塊的流程圖 第四章 linux 音頻編程 音頻編程簡介 音頻信號是一種連續(xù)變化的模擬信號，但計算機(jī)只能處理和記錄二 進(jìn)制的數(shù)字信號，由自然音源得到的音頻信號必須經(jīng)過一定的變換，成為數(shù)字音頻信號之后，才能送到計算機(jī)中作進(jìn)一步的處理。正常人聽覺的頻率范圍大約在20Hz~20kHz 之間，根據(jù)奈奎斯特采樣理論，為了保證聲音不失真，采樣頻率應(yīng)該在 40kHz左右。采集卡的位客觀地反映了數(shù)字聲音信號對輸入聲音信號描述的準(zhǔn)確程度。在 Linux 上進(jìn)行音頻編程的本質(zhì)就是要借助于驅(qū)動程序，來完成對聲卡的各種操作。它可以驅(qū)動很多聲卡并且可以用在很多 UNIX 系統(tǒng)中。為提供向后兼容， ALSA 提供內(nèi)核模塊模仿 OSS/Free 驅(qū)動，所以大多數(shù)的程序不需要改動。 //音頻播放 void read_wav_header(int fd)。 //設(shè)置設(shè)備參數(shù) void alsa_record(char *sendBuffer)。} private: uint32_t sample_rate。 //the point of struct }。 ，參數(shù)設(shè)置不當(dāng)將會導(dǎo)致音頻設(shè)備無法正常工作。而在非交錯模式下，首先記錄的是一個周期內(nèi)所有楨的左聲道樣本，再記錄右聲道樣本，數(shù)據(jù)是以連續(xù)通道的方式存儲。 break 。sample_rate, amp。 if (snd_pcm_hw_params_set_buffer_time_near(handle, hw_params, amp。period_size, amp。 //計算周期長度 snd_pcm_hw_params_free(hw_params)。 (size_t)r count)) { std::cerr Buffer Underrun std::endl。 count = r。 snd_pcm_prepare(handle)。mixer, 0)) 0) { std::cerr snd_mi。 exit(1)。 } } } ，我們再添加一個播放函數(shù)，當(dāng)接收到音頻數(shù)據(jù)時，向音頻設(shè)備寫入數(shù)據(jù)，這個函數(shù)在 class COrtpClient 中： void COrtpClient::play_wav(char *pBuffer) { int rc = 0。 } else if (r == EPIPE) { std::cerr overrun occurred: std::endl。 void CWavPlayer::alsa_record(char *sendBuffer) 嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 19 { int r = 0。 snd_pcm_format_t format。 exit(1)。 //設(shè)置采樣率 uint32_t buffer_time, period_time。 break 。 明白了各參數(shù)含義及關(guān)系后，我們開始設(shè)置參數(shù)： void CWavPlayer::set_pcm_params() { snd_pcm_hw_params_t *hw_params。 （ 1）樣本長度 (sample)：樣本是記錄音頻數(shù)據(jù)最基本的單位，常見的有 8 位和 16 位。 ： void CWavPlayer::open_pcm_devices(snd_pcm_stream_t mode) { int rc。 //采樣位數(shù) uint16_t channels。 //設(shè)置混音器 CWavPlayer amp。 uint32_t snd_read_pcm(uint32_t rcount, char *wave_buf)。 ALSA 還提供一組命令行工具包括 mixer, sound file player 和工具控制一些特別的聲卡的特別的作用。作為一個商業(yè)軟件，你雖然可以使用它，但是你得不到它的源代碼，并且你必須為此而付錢。 OSS/Lite 是現(xiàn)在 linux 內(nèi)核中自帶的聲卡驅(qū)動程序集，最初由 Hannu Savolainen 開發(fā)。比較一下，一段相同的音樂信息， 16位聲卡能把它分為 64K 個精度單位進(jìn)行處理，而 8位聲卡只能處理 256個精度單位， 造成了較大的信號損失，最終的采樣效果自然是無法相提并論的。 （ 2） .采樣的位數(shù) 采樣位數(shù)可以理解為采 集卡處理聲音的解析度。 A/D 轉(zhuǎn)換器以每秒鐘上萬次的速率對聲波進(jìn)行采樣，每個采樣點(diǎn)都記錄下了原始模擬聲波在某一時刻的狀態(tài)，通常稱之為樣本sample），而每一秒鐘所采樣的數(shù)目則稱為采樣頻率，通過將一串連續(xù)的樣本連接起來，就可以在計算機(jī)中描述一段聲音了。非常重要的一點(diǎn)， Linux 還是一種開放、免費(fèi)的操作系統(tǒng)，還具有可移植性和自由代碼等特性，這是其它操作系統(tǒng)所無法比擬的。 混合器和轉(zhuǎn)換器可以針對很多不同的目的而設(shè)計。音頻和視頻采用獨(dú)立的 RTP 會話的原因之一是可以允許部分與會者根據(jù)需要只接收者音頻或視頻流。同時，接收方也可以利用序列號來估算包丟失數(shù)。它通過一個多播地址和一對端口來實(shí)現(xiàn)。其次， RTCP 能實(shí)時監(jiān)控數(shù)據(jù)傳輸和服務(wù)質(zhì)量，嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 6 不需要下層協(xié)議來保證實(shí)時業(yè)務(wù)的服務(wù)質(zhì)量。其中 RTP 被定義為一對一或一對多的傳輸情況下工作，實(shí)現(xiàn)實(shí)時數(shù)據(jù)的傳輸，但是它并不提供任何傳輸可靠性的保證和流量的擁塞控制機(jī)制，這些工作將 由 RTCP 來完成。 RTP（ Realtime Transport Protocol）實(shí)時傳輸協(xié)議，是由 Inter 工程任務(wù)組（ IETF）的音頻 /視頻傳輸工作組制定，主要用于 VoIP、視頻等實(shí)時多媒體信息的傳輸。并且這些可靠的傳輸協(xié)議不能提供時間戳和編解碼信息，而這些信息是接收方應(yīng)用程序所需要的，因此它們是不適合進(jìn)行多媒體信息傳輸?shù)摹? （ 1） .啟動速度慢 即便在網(wǎng)絡(luò)運(yùn)行狀況良好，沒有丟失包的情況下，由于 TCP的建立連接需“三次握手”，嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 4 因而在初始化的過程中，需要較長的時間。 IP 協(xié)議是面向無連接的，負(fù)責(zé)主機(jī)之間的數(shù)據(jù)傳輸，但只提供“盡力而為”（ besteffort）的服務(wù)，不進(jìn)行檢錯和糾錯，因此經(jīng)常發(fā)生數(shù)據(jù)丟失現(xiàn)象。另外，東南大學(xué)計算機(jī)系，北京郵電大學(xué)電信工程學(xué)院和華中科技大學(xué)等研究機(jī)構(gòu)也在這方面做出了大量的研究工作。 國內(nèi)外研究狀況 早在 20 世紀(jì) 70年代末 80 年代初，如何在分組上實(shí)時傳輸語音就是一個很活躍的研究方向，到了九十年代初這個方向研究又變得異?；钴S。 第五章：講解了音頻傳輸?shù)膶?shí)現(xiàn)。然而，語音通信需要的實(shí)時性 是非常高的，而且數(shù)據(jù)量大。 需求分析 [13] ........................................ 錯誤 !未定義書簽。 IV 系統(tǒng)開發(fā)環(huán)境 ................................... 錯誤 !未定義書簽。 C/S 與 B/S 結(jié)構(gòu)的分析比較 .......................... 錯誤 !未定義書簽。 國外著名通用網(wǎng)絡(luò)多媒體教學(xué)平臺 ................. 錯誤 !未定義書簽。 論文的組織結(jié)構(gòu) ................................. 錯誤 !未定義書簽。 RTP/RTCP 使Inter 從理論上具備了處理實(shí)時業(yè)務(wù)的能力，解決了媒體同步問題和滿足了多媒體通信業(yè)務(wù)的要求，現(xiàn)在在 IP 電話、網(wǎng)絡(luò)多媒體會議、遠(yuǎn)程網(wǎng)絡(luò)教學(xué)和遠(yuǎn)程網(wǎng)絡(luò)診斷等領(lǐng)域都有著重大的應(yīng)用。因此， 1996 年 1月 I