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