【正文】 if ((result = snd_mixer_open(amp。 } 嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 21 } } 音量調(diào)整相關(guān)操作 初始 化麥克風(fēng)及本機音量調(diào)節(jié)器相關(guān)代碼： void CWavPlayer::set_pcm_mixer() { snd_mixer_t *mixer。 /* EPIPE means underrun */ //perror(underrun occurred\n)。 snd_pcm_t *handle = ()。 } 嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 20 if (r 0) { result += r。 snd_pcm_prepare(handle)。amp。 size_t count = period_size。 //計算幀大小 chunk_byte = (uint32_t)period_size * bit_per_frame / 8。 snd_pcm_hw_params_get_format(hw_params, amp。 snd_pcm_hw_params_get_period_size(hw_params, amp。 } if (snd_pcm_hw_params_set_period_time_near(handle, hw_params, amp。 period_time = buffer_time / 4。 if (snd_pcm_hw_params_get_buffer_time_max(hw_params, amp。 snd_pcm_hw_params_set_rate_near(handle, hw_params, amp。 case 3:snd_pcm_hw_params_set_format(handle, hw_params, SND_PCM_FORMAT_S24_LE)。 //設(shè)置為交錯模式 switch(bit_per_sample/8) //設(shè)置采樣位數(shù) { case 1:snd_pcm_hw_params_set_format(handle, hw_params, SND_PCM_FORMAT_U8)。 snd_pcm_hw_params_malloc(amp。 交錯模式 (interleaved)：是一種音頻數(shù)據(jù)的記錄方式，在交錯模式下，數(shù)據(jù)以連續(xù)嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 17 楨的形式存放，即首先記錄完楨 1的左聲道樣本和右聲道樣本（假設(shè)為立體聲格式），再開始楨 2的記錄。 （ 2）通道數(shù) (channel)：該參數(shù)為 1 表示單聲道， 2則是立體聲。如果設(shè)備打開成功， pcm_handle 便指向該設(shè)備句柄。 if ((rc = snd_pcm_open(amp。 //周期 WAVHeader_t *wav。 //聲道 uint32_t chunk_byte。} snd_pcm_uframes_t get_period_size() const { return period_size。operator=(CWavPlayer amp。 //print the params of wav struct void set_pcm_params()。 void open_pcm_devices(snd_pcm_stream_t mode = SND_PCM_STREAM_PLAYBACK)。 public: void wav_play(int fd)。 ALSA 音頻編程 ALSA 庫的安裝 在 linux 終端下執(zhí)行： $ sudo aptget install libasound2dev 安裝完畢！ 音頻數(shù)據(jù)的采集和播放的實現(xiàn) 一個典型的音頻程序應(yīng)該具有以下結(jié)構(gòu) ： （ 1）打開音頻設(shè)備 （ 2）為設(shè)備設(shè)置參數(shù)（主要參數(shù)有三個：采樣率、采樣位數(shù)、通道數(shù)） （ 3）向音頻設(shè)備讀 /寫音頻數(shù)據(jù) （ 4）關(guān)閉設(shè)備 Alsa 庫為我們實現(xiàn)這些操作提供了豐富的接口，我們利用 Alsa 接口把語音的采集和播放封裝成一個類 class CWavPlayer，下面是 class CWavPlayer 的部分代碼： class CWavPlayer { 嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 15 public: CWavPlayer(uint32_t sample_rate = 8000, uint16_t bit_per_sample = 16, uint16_t channels = 2)。與此相反 OSS/Free 驅(qū)動在內(nèi)核層次調(diào)用，需要指定設(shè)備名和調(diào)用 ioctl。 ALSA 標(biāo)準(zhǔn)是一個先進的 linux 聲音體系。 OSS/Full 是由 4Front Technologies 開發(fā)并銷售的商業(yè)軟件。后來 Hannu 跑去開發(fā) Open Sound System（也就是上面所說的 OSS/Full）。 出于對安全性方面的考慮， Linux 下的應(yīng)用程序無法直接對聲卡這類硬件設(shè)備進行操作，而是必須通過內(nèi)核提供的驅(qū)動程序才能完成。 常用的采樣位數(shù)有 8位、 12 位和 16 位。采集卡的位是指采集卡在采集和 播放聲音文件時所使用數(shù)字聲音信號的二進制位數(shù)。這個數(shù)值越大，解析度就越高，錄制和回放的聲音就越真實。采樣嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 13 頻率的選擇應(yīng)該遵循奈奎斯特（ Harry Nyquist）采樣理論：如果對某一模擬信號進行采樣，則采樣后可還原的最高信號頻率只有采樣頻率的一半，或者說只要采樣頻率高于輸入信號最高頻率的兩倍，就能從采樣信號系列重構(gòu)原始信號。對于采樣過程中的每一個樣本來說，數(shù)字音頻系統(tǒng) 會分配一定存儲位來記錄聲波的振幅，一般稱之為采樣分辯率或者采樣精度，采樣精度越高，聲音還原時就會越細(xì)膩。接收方則對網(wǎng)絡(luò)層傳來的數(shù)據(jù)包解封，并交由 RTP 提取音頻數(shù)據(jù)，然后進行音頻解壓縮，再經(jīng)揚聲器播放出來。目前 Linux 已經(jīng)得到了越來越多的應(yīng)用。 第三章 實時語音通信系統(tǒng)簡介 系統(tǒng)平臺 本系統(tǒng)是在 linux 下實現(xiàn)的，選 用 Ubuntu 作為軟件的實現(xiàn)平臺， vim 作為編寫工具，編程語言采用 C++。比如視頻混合器，它可以將多路不同的視頻流的單個圖像混合成一路視頻流，模擬一個群體場景。 RTP包頭提供了一個字段 CSRC，使混合器可以辨別混合報文的各個信源，這樣在接收端就可以正確獲知誰是發(fā)送者。盡管采用獨立的 RTP 會話，同源的音頻和視頻可以根據(jù) RTCP 的時間信息進行同步回放。一個與會者離開會議時要發(fā)送 RTCP BYE 報文，以通知其它的參與者自己離開了。 與會者在會議進行期間可能加入或退出，因此了解在某一 時刻有哪些人參加了會議，以及它們的語音數(shù)據(jù)接收情況是很有必要的。 Ier 和其他報文網(wǎng)絡(luò)一樣，會有丟包，報文失序以及報文的不同時延問題。一個端口用于 RTP傳輸音頻數(shù)據(jù)，另一個端口用于傳輸 RTCP 控制包。如果底層網(wǎng)絡(luò)支持多點傳播的話， RTP 還支持使用多點傳播向多個目的 端點發(fā)送數(shù)據(jù)。再次，由于 UDP 的傳輸時延低于 TCP，能與音頻和視頻流很好匹配，保證了實時性的要求。一般來說， RTP 是在傳輸層協(xié)議之上作為應(yīng)用程序的一部分加以實現(xiàn)的。 RTP 和 RTCP 配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，所以特別適合傳輸實時數(shù)據(jù)。它是 IETF 提出的一個標(biāo)準(zhǔn)，對應(yīng)的 RFC 文檔為 RFC3550（ RFC1889 為其過期版 本）。音頻和視頻編碼信數(shù)據(jù)均封裝在 RTP 協(xié)議數(shù)據(jù)包中， RTP 提供定時信息和數(shù)據(jù)報序號，供接收方重組數(shù)據(jù)包，但是 RTP本省并不能為按順序傳送數(shù)據(jù)包提供可靠的傳輸機制，也不提供流量控制或擁塞控制，它依靠 RTCP 提供這些服務(wù)。所以本文在 IP網(wǎng)絡(luò)上建立的實時音頻傳輸系統(tǒng)采用面向無連接的 UDP 協(xié)議進行傳輸。 RTP 的引入 基于上一節(jié)的分析，我們可以清楚的認(rèn)識到 TCP 協(xié)議是不適合用來進行傳輸實時多媒體數(shù)據(jù)的，因此考慮選擇 UDP作為 RTP 的傳輸層協(xié)議。另一方面，音頻、視頻在特定的編碼方式下，產(chǎn)生的編碼數(shù)量是不可能突然改變的，例如，標(biāo)準(zhǔn)的 PCM音頻需要 64Kb/s，加上一些額外控制信息，它不能再低于這個帶寬要求的網(wǎng)絡(luò)上傳輸。而在一個實時多媒體的應(yīng)用中，我們期望盡量少的延遲。但是在大多數(shù)情況下，我們需要再廣域網(wǎng)內(nèi)傳輸數(shù)據(jù)，在這種丟包率較高、網(wǎng)絡(luò)狀況不好的情況下，利用 TCP 協(xié)議進行視頻或音頻通信顯然不是很好的一個選擇。為保證數(shù)據(jù)的可靠傳輸，在傳輸層使用 TCP 協(xié)議，當(dāng)接收端檢測到數(shù)據(jù)包丟失或錯誤時，要求發(fā)送端重新發(fā)送，但這 樣不可避免地引起傳輸延時和占用網(wǎng)絡(luò)帶寬。 實時多媒體數(shù)據(jù)傳輸?shù)奶攸c 實現(xiàn)多媒體數(shù)據(jù)傳輸?shù)暮诵氖锹?、文、圖等多媒體信息的傳輸技術(shù)，它的一個顯著特點是數(shù)據(jù)量大，并且許多應(yīng)用對實時性都有比較高的要求，例如，一個多媒體會議系統(tǒng)，我們總是希望發(fā)言者的發(fā)言能夠盡早讓收聽者收聽到，也就是說時延盡量短 ；另外一個就是我們希望在收聽者收聽語音信息時，一句話平滑的，即中間沒有斷點，也就是等時性。北京的微軟亞洲研究院的網(wǎng)絡(luò)多媒體組正在做 SMART 音 /視頻傳輸(SMART A/V Delivery)等項。還有其他大學(xué)，研究組織研究 開發(fā)出來的音頻工具 TAT（ Robust Audio Tool），會議目錄工具 SDR(session directory)，CUSeeMe 音頻會議工具等等。 1992 年 3月， IETF（ Inter Engineering Task Force）在 San Diego 召開的會議是分組網(wǎng)上第一次大規(guī)模的音頻多播應(yīng)用。隨著IPv6， RSVP,RTP/RTCP 一系列協(xié)議的出現(xiàn)，在 Inter 上實現(xiàn)多媒體通信成為可能。 第六章：介紹了音頻解碼和編碼的實現(xiàn)。 論文的主要內(nèi)容如下： 第一章：引 言，主要介紹了實時多媒體數(shù)據(jù)傳輸?shù)陌l(fā)展，闡述了 TCP 不適合多媒體傳輸?shù)脑虿⒁肓?RTP. 第二章：根據(jù) RFC3550 官方文檔，詳細(xì)分析了 RTP/RTCP 協(xié)議。例如，一個多媒體會議系統(tǒng)，我們總是希望發(fā)言者的發(fā)言能夠盡早讓收聽者收聽到，也就是說時延盡量短；另外一個就是我們希望在收聽者收聽語音信息時，一句話平滑的，即中間沒有斷點，也就是等時性。 數(shù)據(jù)需求 ....................................... 錯誤 !未定義書簽。 系統(tǒng)建設(shè)原則 ................................... 錯誤 !未定義書簽。 技術(shù)可行性 ..................................... 錯誤 !未定義書簽。 平臺的搭建與優(yōu)點 ............................... 錯誤 !未定義書簽。 Ajax 技術(shù) [12] .................................... 錯誤 !未定義書簽。 技術(shù)平臺的介紹 ................................... 錯誤 !未定義書簽。 B/S 體系結(jié)構(gòu) ...................................................... 6 B/S 三層體系結(jié)構(gòu) ............................... 錯誤 !未定義書簽。 存在不足的分析 ................................. 錯 誤 !未定義書簽。 提出的意義 ..................................... 錯誤 !未定義書簽。 系統(tǒng)開發(fā)計劃 ................................... 錯誤 !未定義書簽。 背景 ........................................... 錯誤 !未定義書簽。 本文結(jié)合 RTP/RTCP 高實時性的特點，主要針對局域網(wǎng)，提出了音頻數(shù)據(jù)采用G729a 壓縮，傳輸數(shù)據(jù)采用 ortp 庫，在 linux 平臺下開發(fā)的實時語音通信系統(tǒng)。 當(dāng)前 Inter 中流動的“比特”所代表的內(nèi)容已從原來的數(shù)據(jù)逐漸向?qū)崟r多媒體數(shù)據(jù)演變，它們的特點是對實時性要求非常高。但是， Inter 是建立在 TCP/IP 之上的計算機網(wǎng)絡(luò)，最初設(shè)計時的定位決定了它不適合實時數(shù)據(jù)的傳輸。本文首先介紹了實時傳輸協(xié)議的簡單應(yīng)用后，詳細(xì)分析了 RTP/RTCP 協(xié)議；接著介紹系統(tǒng)的具體實現(xiàn)，主要分三個部分：音頻數(shù)據(jù)的采集和播放，音頻數(shù)據(jù)的解碼和編碼以及音頻數(shù)據(jù)包的發(fā)送和接收。 術(shù)語定義 ....................................... 錯誤 !未定義書簽。 網(wǎng)絡(luò)多媒體教學(xué)系統(tǒng)概述 ............................................ 2 通用網(wǎng)絡(luò)多媒體教學(xué)平臺基本概念 ................. 錯誤 !未定義書簽。 國內(nèi)外網(wǎng)絡(luò)教學(xué)研究發(fā)展?fàn)顩r和分析 ........................