上一期已經講了gating自動混音所應具備的一些基本引數及含義，留下了乙個關鍵點，自適應雜訊閾值如何獲取？在開始之前，先來看看為什麼門限自動混音可以解決上邊提到的問題。
從圖中可以看出，每只麥克風都有個gate（門），當麥克風訊號超過這個門限以後，才會導通訊號。通過的訊號和普通混音無異，混音之後通過乙個由nom（開啟的麥克風數量）控制的衰減因子，達到總輸出不變的目的。 在多隻麥克風的情況下，不會存在每個人都會在同時說話，正在同時說話的麥克風只有那麼1-3只而已。其他未說話的麥克風將被關閉，不會被導通。這樣既可以保證總輸出不產生反饋，每只麥克風說話的聲音又可以聽得清楚。
nom： number of open mics. 演算法實時計算開啟的麥克風數量，如果大於nom limits 設定的數量，新開啟的麥克風將從已經開啟的麥克風中搶占優先順序最低的乙個， 如果沒有找到，該麥克風不會被導通， nom limits起到乙個限制作用。
在這裡面，gate是關鍵，如何保證麥克風有訊號的時候被開啟，沒有人說話就不會被開啟。簡單一點， 可以採用對每乙隻麥克風設定乙個開關閾值，訊號超過閾值的時候就導通，小於閾值就關閉。 在很久以前，就是這麼做的，並且使用了很長的一段時間。此方法不是特別的方便，環境噪音提高了，必須得手動去調整閾值。
在嘗試中，我考慮了2種方法：
1. 人聲檢測 ， 只有說話的時候才被開啟，不說話關閉 。
2. rms電平檢測。
在dsp系統中， 除了能實現模組功能，另乙個最重要的就是資源了。這個演算法占用的cpu資源類不應超過5%， 人聲檢測不能採用太過複雜的基於統計模型的演算法，乙個麥克風需要檢測一次，共有32個麥克風，這將勢必不可取。後來嘗試了短時過零率和短時能量等方法。 結果不太理想，應該來說檢測結果不太理想，有時說話了確不出聲，一句話的前面幾個字像被吃掉了一樣。 總結來說，短時過零率等方法並不能準確判斷語音，第二個這類檢測方法都需要延時緩衝，大概10ms檢測資料，吃字也是正常的。 被拋棄的想法就不細說了，有興趣的可以看看相關資料。
採用rms檢測方法， rms我們都知道，就是均方根嘛。相對來說演算法簡單易實現， 根據過去一段時間的rms值作為該麥克風的參考雜訊閾值。這裡面最重要的就是時間的選取，要反應的是過去的雜訊水平，而不是有訊號的狀態。語音頻號屬於非平穩訊號，利用這一特點應取最小值。 記rn
k 取值依據，應大於說話尾音所能持續的時間，正常說話乙個字也就100多ms，字與字之間會出現停頓，雜訊閾值的依據也就是停頓期間的雜訊水平。 說乙個情況，同事在測試期間，乙個字不停的拖尾音，喂……….，持續10幾秒。 這種情況導致演算法提高了雜訊閾值，剛開始可以導通，之後的喂出不了聲。 那麼這個k值應取得更大，k*30ms 需要大於最大能持續的時間才能檢測到空隙。
根據測試情況，rms方法可以作為自適應雜訊閾值判斷的方法。在測試中，會存在另外一種情況，乙隻麥克風說話時，另乙隻麥克風採集到了音箱擴聲的訊號被開啟。如果nom limit設定成1，只允許乙個麥克風開啟。採集訊號的麥克風就會搶占說話的麥克風，引起兩個麥克風互相切換。此時，應調節2個引數，一是保持時間，第二個靈敏度。
保持時間，停止說話後，該麥克風保持多久才關閉，改時間要設定得比混響傳遞時間大一點。
靈敏度，實際上訊號超過自適應雜訊閾值+靈敏度才能判定為可以開啟麥克風。靈敏度需要設定高一點，即使有反饋也不會輕易開啟話筒。
以上就是gating自動混音的全部內容，**就不貼了，也沒什麼意義，關鍵還是思路吧。
大家有什麼更好的方法或者疑問，可以發郵件給我。
Linux音訊程式設計（三）混音器介紹
一 介紹 1 mixer 用來控制多個輸入 輸出的音量,也控制輸入 microphone,line in,cd 之間的切換，可以將多個訊號組合或者疊加在一起。音效卡上的混音器由多個混音通道組成，它們可以通過音效卡驅動程式提供的裝置檔案 dev mixer進行程式設計 對混音器進行操作的軟體介面 混音...
網路自動校時器
if strtotime 06 01 01 strtotime timetostr time then 呼叫 begin timer1.enabled false verifystandardtime 校驗標準時間 timer1.enabled true end procedure tmyservi...
Grunt 自動任務執行器
b 幹什麼用？b 基於node.js的一款能夠按照預先設定的順序自動執行一系列任務的工具。簡化工作流程，減輕重複性工作帶來的負擔。b 如何使用？b 1.安裝 sudo npm install grunt cli g 2.命令指令碼檔案gruntfile.js 用於配置或定義任務 載入 grunt 外...