示例代碼托管在： "http://www.github.com/dashnowords/blogs" 博客園地址： "《大史住在大前端》原創博文目錄" 華為雲社區地址： "【你要的前端打怪升級指南】" [TOC] 本文中最重要的信息：32為浮點數表示 位深數據時是用 1~+1的小數來表示16位的 3 ...
目錄
示例代碼托管在：http://www.github.com/dashnowords/blogs
博客園地址：《大史住在大前端》原創博文目錄
華為雲社區地址：【你要的前端打怪升級指南】
本文中最重要的信息：32為浮點數表示
16bit位深數據時是用-1~+1的小數來表示16位的-32768~+32767的！翻遍了MDN都沒找到解釋，我的內心很崩潰！
最近不少朋友需要在項目中對接百度語音識別的REST API介面，在讀了我之前寫的【Recorder.js+百度語音識別】全棧方案技術細節一文後仍然對Web音頻採集和處理的部分比較困惑，本文僅針對音頻流處理的部分進行解釋，全棧實現方案的技術要點，可以參見上面的博文，本篇不再贅述。
一. PCM格式是什麼
百度語音官方文檔對於音頻文件的要求是：
pcm,wav，arm及小程式專用的m4a格式，要求參數為16000採樣率，16bit位深，單聲道。
PCM編碼，全稱為"脈衝編碼調製"，是一種將模擬信號轉換成數字信號的方法。模擬信號通常指連續的物理量，例如溫度、濕度、速度、光照、聲響等等，模擬信號在任意時刻都有對應的值；數字信號通常是模擬信號經過採樣、量化和編碼等幾個步驟後得到的。
比如現在麥克風采集到了一段2秒的音頻模擬信號，它是連續的，我們有一個很菜的音效卡，採集頻率為10Hz，那麼經過採樣後就得到了20個離散的數據點，這20個點對應的聲音值可能是各種精度的，這對於存儲和後續的使用而言都不方便，此時就需要將這些值也離散化，比如在上例中，信號的範圍是0~52dB，假設我們希望將0~63dB的值都以整數形式記錄下來，如果採用6個bit位來存儲，那麼就可以識別（2^6-1=63）個數值，這樣採集的信號通過四捨五入後都以整數形式保存就可以了，最小精度為1dB；如果用7個bit位來保存，可存儲的不同數值個數為(2^7-1=127)個，如果同樣將0~63dB映射到這個範圍上的話，那麼最小精度就是0.5dB，很明顯這樣的處理肯定是有精度損失的，使用的位數越多精度越高，電腦中自然需要使用8的整數倍的bit位來進行存儲，經過上述處理後數據就被轉換成了一串0和1組成的序列，這樣的音頻數據是沒有經過任何壓縮編碼處理的，也被稱為“裸流數據”或“原始數據”。從上面的示例中很容易看出，用10Hz的採樣率，8bit位存儲採樣點數值時，記錄2秒的數據一共會產生2X10X8 = 160個bit位，而用16bit位來存儲採樣點數據時，記錄1秒的數據也會產生1X10X16 = 160個bit位，如果沒有任何附加的說明信息，就無法知道這段數據到底該怎麼使用。按照指定要求進行編碼後得到的序列就是pcm數據，它在使用之前通常需要聲明採集相關的參數。
下圖就是一段採樣率為10Hz，位深為3bit的pcm數據，你可以直觀地看到每個步驟所做的工作。
wav格式也是一種無損格式，它是依據規範在pcm數據前添加44位元組長度用來填充一些聲明信息的，wav格式可以直接播放。而百度語音識別介面中後兩種格式都需要經過編碼演算法處理，通常會有不同程度的精度損失和體積壓縮，所以在使用後兩種數據時必然會存在額外的編解碼時間消耗，所以不難看出，各種格式之間的選擇其實就是對時間和空間的權衡。
二. 瀏覽器中的音頻採集處理
瀏覽器中的音頻處理涉及到許多
API的協作，相關的概念比較多，想要對此深入瞭解的讀者可以閱讀MDN的【Web 媒體技術】篇，本文中只做大致介紹。
首先是實現媒體採集的WebRTC技術，使用的舊方法是navigator.getUserMedia( ),新方法是MediaDevices.getUserMedia( )，開發者一般需要自己做一下相容處理，麥克風或攝像頭的啟用涉及到安全隱私，通常網頁中會有彈框提示，用戶確認後才可啟用相關功能，調用成功後，回調函數中就可以得到多媒體流對象，後續的工作就是圍繞這個流媒體展開的。
瀏覽器中的音頻處理的術語稱為AudioGraph，其實就是一個【中間件模式】，你需要創建一個source節點和一個destination節點，然後在它們之間可以連接許許多多不同類型的節點，source節點既可以來自流媒體對象，也可以自己填充生成，destination可以連接預設的揚聲器端點，也可以連接到媒體錄製APIMediaRecorder來直接將pcm數據轉換為指定媒體編碼格式的數據。中間節點的類型有很多種，可實現的功能也非常豐富，包括增益、濾波、混響、聲道的合併分離以及音頻可視化分析等等非常多功能(可以參考MDN中給出的AudioContext可創建的不同類型節點)。當然想要熟練使用還需要一些信號處理方面的知識，對於非工科背景的開發者而言並不容易學習。
三. 需求實現
一般的實現方法是從getUserMedia方法得到原始數據，然後根據相關參數手動進行後處理，相對比較繁瑣。
方案1——服務端FFmpeg實現編碼
很多示例都是將音頻源節點直接連接到預設的輸出節點（揚聲器）上，但是幾乎沒什麼意義，筆者目前還沒有找到使用Web Audio API自動輸出pcm原始採樣數據的方法，可行的方法是使用MediaRecorder來錄製一段音頻流，但是錄製實例需要傳入編碼相關的參數並指定MIME類型，最終得到的blob對象通常是經過編碼後的音頻數據而非pcm數據，但也因為經過了編碼，這段原始數據的相關參數也就已經存在於輸出後的數據中了。百度語音官方文檔推薦的方法是使用ffmpeg在服務端進行處理，儘管明顯在音頻的編解碼上繞了彎路，但肯定比自己手動編碼難度要低得多，而且ffmepg非常強大，後續擴展也方便。參考數據大致從錄音結束到返回結果，PC端耗時約1秒，移動端約2秒。
核心示例代碼(完整示例見附件或開頭的github代碼倉)：
//WebRTC音頻流採集
navigator.mediaDevices.getUserMedia({audio:true})
.then((stream) => {
//實例化音頻處理上下文
ac = new AudioContext({
sampleRate:16000 //設置採樣率
});
//創建音頻處理的源節點
let source = ac.createMediaStreamSource(stream);
//創建音頻處理的輸出節點
let dest = ac.createMediaStreamDestination();
//直接連接
source.connect(dest);
//生成針對音頻輸出節點流信息的錄製實例,如果不通過ac實例調節採樣率，也可以直接將stream作為參數
let mediaRecorder = window.mediaRecorder = new MediaRecorder(dest.stream, {
mimeType: '',//chreome中的音軌預設使用格式為audio/webm;codecs=opus
audioBitsPerSecond: 128000
});
//給錄音機綁定事件
bindEventsForMediaRecorder(mediaRecorder);
})
.catch(err => {
console.log(err);
});錄音機事件綁定：
//給錄音機綁定事件
function bindEventsForMediaRecorder(mediaRecorder) {
mediaRecorder.addEventListener('start', function (event) {
console.log('start recording!');
});
mediaRecorder.addEventListener('stop', function (event) {
console.log('stop recording!');
});
mediaRecorder.addEventListener('dataavailable', function (event) {
console.log('request data!');
console.log(event.data);//這裡拿到的blob對象就是編碼後的文件，既可以本地試聽，也可以傳給服務端
//用a標簽下載;
createDownload(event.data);
//用audio標簽載入
createAudioElement(event.data);
});
}本地測試時，可以將生成的音頻下載到本地，然後使用ffmpeg將其轉換為目標格式：
ffmpeg -y -i record.webm -f s16le -ac 1 -ar 16000 16k.pcm詳細的參數說明請移步ffmpeg documentation，至此就得到了符合百度語音識別介面的錄音文件。
方案2——ScriptProcessorNode手動處理數據流
如果覺得使用ffmpeg有點“殺雞用牛刀”的感覺，那麼就需要自己手動處理二進位數據了，這是就需要在audioGraph中添加一個腳本處理節點scriptProcessorNode，按照MDN的信息該介面未來會廢棄，用新的Audio Worker API取代，但目前chrome中的情況是，Audio Worker API標記為試驗功能，而舊的方法也沒有明確的提示說明會移除（通常計劃廢除的功能，控制台都會有黃色字體的提示）。但無論如何，相關的基本原理是一致的。
scriptProcessorNode節點使用一個緩衝區來分段存儲流數據，每當流數據填充滿緩衝區後，這個節點就會觸發一個audioprocess事件（相當於一段chunk），在回調函數中可以獲取到該節點輸入信號和輸出信號的記憶體位置指針，然後通過手動操作就可以進行數據處理了。
先來看一個簡單的例子，下麵的示例中，處理節點什麼都不做，只是把單聲道輸入流直接拷貝到輸出流中：
navigator.mediaDevices.getUserMedia(constraints)
.then((stream) => {
ac = new AudioContext({
sampleRate:16000
});
let source = ac.createMediaStreamSource(stream);
//構造參數依次為緩衝區大小，輸入通道數，輸出通道數
let scriptNode = ac.createScriptProcessor(4096, 1, 1);
//創建音頻處理的輸出節點
let dest = ac.createMediaStreamDestination();
//串聯連接
source.connect(scriptNode);
scriptNode.connect(dest);
//添加事件處理
scriptNode.onaudioprocess = function (audioProcessingEvent) {
//輸入流位置
var inputBuffer = audioProcessingEvent.inputBuffer;
//輸出流位置
var outputBuffer = audioProcessingEvent.outputBuffer;
//遍歷通道處理數據，當前只有1個輸入1個輸出
for (var channel = 0; channel < outputBuffer.numberOfChannels; channel++) {
var inputData = inputBuffer.getChannelData(channel);
var outputData = outputBuffer.getChannelData(channel);
//用按鈕控制是否記錄流信息
if (isRecording) {
for (let i = 0; i < inputData.length; i = i + 1) {
//直接將輸入的數據傳給輸出通道
outputData[i] = inputData[i];
}
}
};
}在上面的示例加工後，如果直接將結果連接到ac.destination（預設的揚聲器節點）就可以聽到錄製的聲音，你會聽到輸出信號只是重覆了一遍輸入信號。
但是將數據傳給
outputData輸出後是為了在後續的節點中進行處理，或者最終作為揚聲器或MediaRecorder的輸入，傳出後就無法拿到pcm數據了，所以只能自己來假扮一個MediaRecorder。
首先在上面示例中向輸出通道透傳數據時，改為自己存儲數據，將輸入數據列印在控制台後可以看到緩衝區大小設置為4096時，每個chunk中獲取到的輸入數據是一個長度為4096的Float32Array定型數組，也就是說每個採樣點信息是用32位浮點來存儲的，【recorder.js】給出的轉換方法如下：
function floatTo16BitPCM(output, offset, input) {
for (let i = 0; i < input.length; i++, offset += 2) {
let s = Math.max(-1, Math.min(1, input[i]));
output.setInt16(offset, s < 0 ? s * 0x8000 : s * 0x7FFF, true);
}
}看起來的確是不知道在幹嘛，後來參考文獻中找到了相關解釋：
32位存儲的採樣幀數值，是用
-1到1來映射16bit存儲範圍-32768~32767的。
現在再來看上面的公式就比較容易懂了：
//下麵一行代碼保證了採樣幀的值在-1到1之間，因為有可能在多聲道合併或其他狀況下超出範圍
let s = Math.max(-1, Math.min(1, input[i]));
//將32位浮點映射為16位整形表示的值
output.setInt16(offset, s < 0 ? s * 0x8000 : s * 0x7FFF, true);如果s>0其實就是將0~1映射到到0~32767，正數第一位符號位為0，所以32767對應的就是0111 1111 1111 1111也就是0x7FFF，直接把s當繫數相乘就可以了；當s為負數時，需要將0~-1映射到0~-32768，所以s的值也可以直接當做比例繫數來進行轉換計算，負數在記憶體中存儲時需要使用補碼，補碼是原碼除符號位以外按位取反再+1得到的，所以-32768原碼是1000 0000 0000 0000（溢出的位直接丟棄）,除符號位外按位取反得到1111 1111 1111 1111,最後再+1運算得到1000 0000 0000 0000(溢出的位也直接丟棄)，用16進位表示就是0x8000。順便多說一句，補碼的存在是為了讓正值和負值在二進位形態上相加等於0。
公式里的output很明顯是一個ES6-ArrayBuffer中的DataView視圖，用它可以實現混合形式的記憶體讀寫，最後的true表示小端系統讀寫，對這一塊知識不太熟悉的讀者可以閱讀阮一峰前輩的ES6指南（前端必備工具書）進行瞭解。
參考文獻
how-to-convert-between-most-audio-formats-in-net。
