1 引言
　　在Win32 APIs基礎上編寫錄音程序繁瑣易錯，使用封裝好的類是個不錯的注意。不幸的是所謂封裝好的類對你而言，往往是代碼羅嗦且功能不足，因此盡管你可能希望在某個項目上因使用封裝好的類而避開Win32 APIs，可最終你發現你還得面對它。不是為了編寫自己的類，就是為了修改別人的代碼。
　　Win32 APIs中有一組被稱成多媒體控制接口（即MCI）的函數，該接口提供了多媒體編程所需的系統級APIs。對絕大多數C/C++程序員而言，這些函數也就是Windows多媒體編程的最低層接口。
　　由于錄音代碼直接操作真實的錄音設備而非單純的邏輯過程，因此會遇到一些“意外”或與時序有關的困難，從而使編寫健壯的代碼成了一件困難的事。
　　錄音的目的往往是將聲音寫入文件保存下來或是通過網絡發送，這兩類需求對錄音代碼影響較大。前者無實時性要求，一般也不限制數據量，代碼較易編寫，而后者既對實時性又要求，又對數據量（也就是音頻格式）有要求，且網絡系統的穩定性也難比文件系統。期望在本文中試圖解決所有的問題是不現實的，諸如如何壓縮音頻數據以減小網絡帶寬需求或如何通過網絡傳輸音頻數據之類的問題，讀者需參閱專業著作，本文只講述如何獲得適宜某類需求的原始音頻數據。
　　本文中的示例代碼均是一個名為CWaveRecord的錄音類的成員函數，該類是一個網絡電話程序的核心類。為減小篇幅或簡單明了，作了簡化處理等。
　　2 基本過程
　　MCI按打開設備、配置設備、實現功能（或曰發送命令）、撤銷配置、關閉設備的標準次序組織APIs。對于錄音編程而言，其要點在于根據音頻格式打開對應的設備、配置錄音所需的參數（主要是設置數據區以及根據數據接收方式設置回調函數或消息）、按一定次序發送命令給設備、接收數據并配置參數以繼續錄音、停止錄音釋放資源、關閉設備等幾個步驟上。所需的函數說明于mmsystem.h，引入庫是winmm.lib。
　　2.1 打開設備
　　調用waveInOpen()打開錄音設備，打開成功后函數返回MMSYSERR_NOERROR，而第一個參數返回設備句柄。
　　調用該函數時，必須指定設備表示符（可能有多個設備）、音頻格式以及返回音頻數據的方式。
　　你可以將設備表示符，即第二個參數設為WAVE_MAPPER。這意味著，你不在意具體使用哪個設備，由系統決定。
　　第三個參數是個WAVEFORMATEX結構指針，對應的結構指定音頻格式。一個音頻格式結構的例子：
　　PCMWAVEFORMAT wf_PCM8S11K =
　　{
　　 {
　　 WAVE_FORMAT_PCM, // PCM格式
　　 1, // 單聲道
　　 11025L, // 11.025KHZ
　　 11025L, // 11025字節/s
　　 1 // 字節對齊
　　 },
　　 8 // 8位采樣
　　};
　　后面的三個參數用于指定獲取音頻數據的方式：事件方式、線程方式、窗口方式以及回調函數方式。最后一個參數，即第六個參數指定方式，而第四個參數和第五個參數指定該方式所需的信息。
　　調用示例：
　　waveInOpen( &m_hWaveIn, dwDeviceID, m_pwf,
　　(DWORD)waveInProc, (DWORD)this, CALLBACK_FUNCTION );
　　該示例使用回調函數方式獲取音頻數據。其中dwDeviceID通常即為WAVE_MAPPER，m_pwf指向音頻格式結構，缺省值即wf_PCM8S11K的地址，waveInProc是回調函數（內部細節后面論述）。值得注意的是，this指針被設為實例數據，這是一個編程小技巧，方便waveInProc調用處理函數。
　　2.2 配置設備
　　按指定音頻格式成功打開錄音設備之后，需要配置錄音設備，也即為音頻數據分配數據區。需要考慮的第一個問題是數據塊的個數和大小。
　　系統一般在填滿一個數據塊后將其返回，這意味著大的數據塊導致獲取數據的頻率降低。如果試圖通過網絡傳輸這些數據，這意味著傳輸次數降低，但每次傳輸的數據量較大，這將導致音頻的實時性降低。另外，在網絡傳輸過程中，數據包（指每次發送的UDP或TCP數據包）的開始一般需設置一個信息頭，紀錄本數據包所含音頻數據的長度、錄制起始時間、錄制時間、發送時間、識別用的標識符以及其他一些信息，方便接受者處理。如果設置的音頻數據塊太小，比如100字節，將導致低的網絡傳輸效率。這意味著網絡將為小量數據啟動傳輸過程，而這小量數據中又有相當一部分屬于附加信息，這是不合算的。
　　數據塊的個數相對來說要好處理的多。較多的數據塊只有一個問題，那就是浪費，但這對Windows這樣的操作系統而言，浪費幾百K的內存根本不是問題。數據塊個數不能太少，這是因為在你處理上次返回的數據塊時，錄音設備正在工作，需要內存。如果在某一段時間內，比如說網絡傳輸變壞，你處理數據的速度也將變慢，而錄音設備卻如常工作。這導致你無法迅速地返回當前內存供下一次錄音使用，因此需要一些備用的內存塊以備不時之需。
　　調用waveInAddBuffer為錄音設備配置數據塊，而在此之前需調用waveInPrepareHeader準備數據塊。
　　WaveInPrepareHeader的參數有三個，就是錄音設備句柄、一個描述數據塊的結構WAVEHDR和該結構的大小。
　　WAVEHDR結構是錄音編程的常用數據結構，不同的使用環境設置不同的參數，具體內容參見MSDN。
　　下面的示例為錄音設備添加4個大小為4096字節的數據塊：
　　 for( i=0; i<4; i++ )
　　 {
　　 pwh = (WAVEHDR*)malloc( 4096 + sizeof(WAVEHDR) )
　　 ZeroMemory( pwh, sizeof(WAVEHDR) );
　　 pwh->dwBufferLength = 4096;
　　 pwh->lpData = (LPSTR)(pwh + 1);
　　 waveInPrepareHeader( hWaveIn, pwh, sizeof(WAVEHDR) );
　　 waveInAddBuffer( hWaveIn, pwh, sizeof(WAVEHDR) );
　　}
　　每次添加數據塊都需一個WAVEHDR（其他操作也如此），能否讓這些數據塊共用一個WAVEHDR或使用局部變量以減少內存消耗呢？最好不要這么做，因為你是在與實際設備打交道。很可能當調用返回時，系統內部卻還在使用WAVEHDR結構。如果共用或使用局部變量將導致信息混亂或非法內存操作。這一點MSDN沒有強調，我花了一星期才得到如此教訓。其他錄音操作也類似于此，切記！
　　配置好內存以后就可啟動錄音了：
　　waveInStart( hWaveIn );
　　如果所有操作均正確，很快你將得到第一塊音頻數據。
　　2.3 處理音頻數據塊
　　獲取音頻數據塊的方式有多種（詳見MSDN），處理方式大同小異，本文以回調函數方式為例說明處理過程。如上所述，waveInProc在waveInOpen調用中被設置為回調函數。
　　waveInProc通過處理WIM_OPEN（打開設備）、WIM_DATA（音頻數據）、WIM_CLOSE（設備關閉）消息的方式與系統交互，通常只需處理WIM_DATA消息，其他兩條消息可以忽略。
　　當系統返回一個音頻數據塊時，系統調用回調函數。此時，回調函數第一個參數被設置為錄音設備句柄；第二個參數是消息，即WIM_DATA；第三個參數則是在waveInOpen第五個參數中給出的實例數據；其他參數是與消息有關的參數，參見MSDN。
　　 處理WIM_DATA的任務由成員函數OnWaveInData完成，因此waveInProc及其簡單：
　　 CWaveRecord *pObject = (CWaveRecord *)dwInstance;
　　 if( uMsg == WIM_DATA )
　　 pObject->OnWaveInData( (WAVEHDR*)dwParam1 );
　　 在OnWaveInData中需要完成兩件事：一是保存系統返回的音頻數據，二是給錄音設備添加數據塊以繼續錄音，否則會因數據塊耗盡而停止錄音。
　　在保存系統返回的音頻數據塊之前，需要調用waveInUnprepareHeader發送一個通知告訴設備驅動程序該數據塊已不能用于錄音。保存音頻數據塊是個單純的數據保存問題，不需多說，只是有三個要點需要特別關注：
　　一是MSDN中注明在回調函數中嚴格限制系統調用，因此你不能隨心所欲地設計方案，比如說直接將音頻數據寫入文件是不允許的。通常，你需要設計一個數據塊鏈表結構進行緩沖，這多半涉及多線程編程。特別是如果你使用MFC中的CSocket類，那么必須清楚CSocket依賴一個名為CSocketWnd的內部類，而該類與TLS（線程局部存貯）有關，這意味著CSocket類是不支持多線程共享的。然而，Win32的SOCKET句柄是全局性。因此，獲取CSocketWnd類對象的窗口句柄之后，我通過直接調用Win32 APIs使用CSocket::m_hSocket避開這個由MFC封裝引起的問題。
　　二是系統是在另一個線程（不是你自己創建的線程）中調用回調函數，這會給使用TLS機制的程序帶來一些微妙的影響。如果你使用MFC，AfxGetApp之類的函數返回值不正確。
　　三是盡可能地快速。
　　至于給錄音設備添加數據塊以繼續錄音，其步驟與初始化過程一樣：
　　waveInPrepareHeader( hWaveIn, pwh, sizeof(WAVEHDR));
　　waveInAddBuffer( hWaveIn, pwh, sizeof(WAVEHDR) );
　　2.4 關閉設備釋放資源
　　簡單的調用waveInClose即可關閉設備。不過，在關閉時必須保證所有錄音數據塊已全部返回，這有點麻煩。我的解決方法是設置一個停止錄音標志和一個錄音數據塊計數。當用戶發出停止錄音的命令后，該標志置為TRUE，而OnWaveInData（在回調函數中被調用）檢查該標志，在標志置位的情況下，OnWaveInData不添加錄音數據塊。每添加一個錄音數據塊計數增加，每返回一個則減少（均在OnWaveInData中實現）。執行停止錄音命令時，先將停止標志值位，等待計數變為零，然后才調用waveInClose。需要注意的是，計數涉及多線程數據共享，應使用線程互斥機制，在單CPU的機子上使用InterlockedIncrement和InterlockedDecrement是個簡單的選擇。
　　3 編程技巧
　　3.1 簡單的聲音檢測
　　如果你通過網絡發送音頻數據，自然需要進行音頻處理。專業級的處理難度相當高，如果你是在一個局域網上進行通話，那么無需進行音頻壓縮也可以將就使用（性能自然不高）。但如果你不說話，程序還不停地發送音頻數據（靜音或噪音），那就太說不過去了。
　　你可以定義一個靜音區間，一旦音頻強度進入該區間就意味著沒有聲音。統計音頻數據塊中不是靜音采樣點的個數，當總數超過預設的限制時，才發送該數據塊。
　　對于8位采樣，127是靜音點。簡單的代碼如下：
　　 for( i=0; i<nMax; i++ )
　　 {
　　 uValue = (UCHAR)data[i];
　　 if( uValue<=125 || uValue>=129 )
　　 uHasCnt++;
　　 if( uHasCnt >= uLestNum )
　　 return TRUE;
　　 }
　　return FALSE;
　　3.2 創建音頻文件
　　創建任意格式的音頻文件在編程上不是一件輕松的事，但對于8位單聲道音頻數據而言較容易。定義文件信息頭結構：
　　// wav文件頭結構, 對齊方式為1字節
　　typedef struct
　　{
　　char RiffId[4]; // "RIFF"
　　 DWORD dwFileDataSize; // file size - 8
　　 char WaveId[4]; // "WAVE"
　　 char FMTId[4]; // "fmt "
　　 DWORD dwFmtSize; // 16
　　 WORD wFormatTag; // WAVE_FORMAT_PCM
　　 WORD wChannels; // 1
　　 DWORD dwSamplesPerSec; // 11025
　　 DWORD dwAvgBytesPerSec; // 11025
　　 WORD wBlockAlign; // 1
　　 WORD wBitsPerSample; // 8
　　 char DataId[4]; // "data"
　　 DWORD dwDataSize;
　　} WAVEFILEHDR, *PWAVEFILEHDR;
　　打開文件時，預留該結構大小的空間：
　　SetFilePointer(hFile,sizeof(WAVEFILEHDR), NULL, FILE_BEGIN );
　　然后就如寫一般文件一樣將接收的音頻數據寫入文件：
　　 WriteFile(hFile,pwh->lpData,pwh->dwBytesRecorded,&n, NULL );
　　 m_dwSizeWrite += dwSize;
　　最后一行代碼是將寫入的數據量統計下來用于信息頭填寫。
　　在關閉音頻文件時填寫信息頭：
　　 WAVEFILEHDR wfd =
　　 {
　　 'R', 'I', 'F', 'F', 0,
　　 'W', 'A', 'V', 'E',
　　 'f', 'm', 't', ' ', 16,
　　 WAVE_FORMAT_PCM, 1, 11025, 11025, 1, 8,
　　 'd', 'a', 't', 'a', 0
　　 };
　　 wfd.dwFileDataSize = dwBytes + sizeof(WAVEFILEHDR)- 8;
　　 wfd.dwDataSize = dwBytes;
　　 ::SetFilePointer( hFile, 0, NULL, FILE_BEGIN );
　　 ::WriteFile( hFile, &wfd, sizeof(wfd), &dwSize, NULL );
　　參考文獻
　　1 Visual C++ 6.0 MSDN
　　2 Win32程序員開發指南（二）
　　3 Visual C++ 6.0附帶MFC源碼

總結

以上是生活随笔為你收集整理的Win32下的录音编程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。