目錄

• 一. PCM格式是什麼
• 二. 瀏覽器中的音訊採集處理
• 三. 需求實現
  • 方案1——服務端FFmpeg實現編碼
  • 方案2——ScriptProcessorNode手動處理資料流
• 參考文獻

示例程式碼託管在：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

下圖就是一段取樣率為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-ne