JavaScript基礎修煉(14)——WebRTC在瀏覽器中如何得到指定格式的PCM數據

時間 2019-11-07

標籤 javascript 基礎修煉 webrtc 瀏覽器如何得到指定格式 pcm 數據欄目 JavaScript 简体版

原文原文鏈接

目錄html

示例代碼託管在：http://www.github.com/dashnowords/blogs前端

博客園地址：《大史住在大前端》原創博文目錄node

華爲雲社區地址：【你要的前端打怪升級指南】git

本文中最重要的信息：32爲浮點數表示16bit位深數據時是用-1~+1的小數來表示16位的-32768~+32767的！翻遍了MDN都沒找到解釋，個人心裏很崩潰！github

最近很多朋友須要在項目中對接百度語音識別的REST API接口，在讀了我以前寫的【Recorder.js+百度語音識別】全棧方案技術細節一文後仍然對Web音頻採集和處理的部分比較困惑，本文僅針對音頻流處理的部分進行解釋，全棧實現方案的技術要點，能夠參見上面的博文，本篇再也不贅述。web

一. PCM格式是什麼

百度語音官方文檔對於音頻文件的要求是：算法

pcm,wav，arm及小程序專用的m4a格式，要求參數爲16000採樣率，16bit位深，單聲道。chrome

PCM編碼，全稱爲"脈衝編碼調製"，是一種將模擬信號轉換成數字信號的方法。模擬信號一般指連續的物理量，例如溫度、溼度、速度、光照、聲響等等，模擬信號在任意時刻都有對應的值；數字信號一般是模擬信號通過採樣、量化和編碼等幾個步驟後獲得的。shell

好比如今麥克風採集到了一段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指南（前端必備工具書）進行了解。