【導(dǎo)讀】音頻信號處理產(chǎn)品的設(shè)計和編碼軟件有其獨特的挑戰(zhàn)。那么，開發(fā)人員最常犯的錯誤是什么？如何避免這些錯誤呢？
無論最終產(chǎn)品是什么，無論他們使用什么語言編寫代碼，世界各地的軟件開發(fā)人員都面臨著同樣的挑戰(zhàn)——不斷變化的客戶需求、緊迫的交期、整合和客戶支持，以上只是幾個例子。
但是有一種類型的軟件開發(fā)涉及了解和解決非常具體的問題。音頻信號處理產(chǎn)品的設(shè)計和編碼軟件有其獨特的挑戰(zhàn)。那么，開發(fā)人員最常犯的錯誤是什么？如何避免這些錯誤呢？
了解信號處理對于在音頻領(lǐng)域工作的軟件工程師很有幫助，但這不是必需的。然而，有些領(lǐng)域?qū)σ纛l有一些了解確實有所幫助。
首先，是增益結(jié)構(gòu)，了解音量控制可以為我們的系統(tǒng)增加增益。這適用于我們軟件的內(nèi)部結(jié)構(gòu)，并將影響我們插入原型的所有小工具。結(jié)果可能是聲音輸出令人不滿意。開發(fā)人員以為這是由于代碼中的錯誤造成的，而實際上這是增益結(jié)構(gòu)的問題。知道這一點可以在不必要的調(diào)試中節(jié)省大量時間。
其次，軟件開發(fā)人員有時會忘記音頻濾波會增加群延遲。如果我們忘記了這個基本事實，我們可能會過分承諾我們的算法的性能，我們會認為它會比實際行動得更快。
第三，一個雖然很小但很重要的點是實際數(shù)據(jù)和理論數(shù)據(jù)之間的差異。數(shù)學(xué)有零，但音頻沒有。在數(shù)學(xué)中，算法的設(shè)計使用理論數(shù)據(jù)。當使用實際數(shù)據(jù)測試我們的系統(tǒng)時，我們可能會發(fā)現(xiàn)一個信號似乎是無聲的。在那種情況下，放大它總是值得的——它可能有點嘶嘶聲，也可能全是零。
最后，我們不可能只采用一種算法并將其部署在所有設(shè)備上。我們需要在開發(fā)過程中盡早考慮我們的算法將要有的部署約束條件。一些DSP非常高效且功耗低，但它們的內(nèi)存可能有限。其他的可能非常適合用于AI處理，但它們會引入更高的延遲。如果你能設(shè)計一個權(quán)衡空間和時間的算法，那就太好了。但實際上，大多數(shù)算法無法做到這一點，因此我們可能會發(fā)現(xiàn)自己無法獲得功耗最低的嵌入式設(shè)備。
在任何開發(fā)中，在開發(fā)開始之前了解客戶需求是必不可少的。但在處理音頻時，這一點更為重要。為什么呢？因為對于音頻，客戶不僅需要一個運行良好的系統(tǒng)，他們還需要一個可以輸出出色音頻的系統(tǒng)。問題是每個人聽到的聲音都不一樣(例如，年齡會影響聽力敏銳度)，而且我們對聽起來“好”的聲音都有個人偏好。我們可能會發(fā)現(xiàn)我們花了很長時間開發(fā)的一種產(chǎn)品，最終客戶根本不喜歡。
對于大多數(shù)音頻開發(fā)人員來說，這是一個持續(xù)存在的問題。音頻的評估比視覺算法的評估更難。這是為什么？因為視覺結(jié)果可以并排放置并同時將它們相互進行比較。但你不能同時比較音頻：你不能同時聽兩件事。因此，音頻結(jié)果的A/B測試只能是順序的，不能同時進行。所以，測試音頻需要更長的時間，我們可能需要聽兩個小時的測試錄音僅僅是為了評估對算法的小調(diào)整。我們要確保項目的計劃包含有比我們認為需要的更長的測試時間。
我們可以通過商定使用一種普遍被接受的音頻測試指標(例如MOS分數(shù))來避免這種主觀性。這些輸入的音頻和預(yù)期所需的觀眾對結(jié)果的評價。確實有助于評估質(zhì)量，但不會給我們提供改進的原因。許多常見的測試和指標是為有線電話等傳統(tǒng)的現(xiàn)有應(yīng)用開發(fā)的，并且偏向于這些應(yīng)用。因此，使用指標會有所幫助，但這不是絕對的答案。在我們開始工作之前，要確保我們的客戶把他們的愿景告訴我們，因為他們希望音頻聽起來像什么，這一點至關(guān)重要。
了解客戶的愿景對于下一個要注意的問題整合也很重要。我們的音頻是系統(tǒng)的一部分。所有部分都必須協(xié)同工作，但系統(tǒng)的其余部分受處理音頻的消耗限制，而我們的音頻也受系統(tǒng)其余部分消耗的限制。如果音頻在實際的系統(tǒng)上斷斷續(xù)續(xù)，那么在空的系統(tǒng)上開發(fā)運行良好的東西是沒有意義的，而且會浪費很多資源。所以，早點整合吧。但是，正如開發(fā)人員都知道的，整合的成本很高。為了防止將時間浪費在整合不合適的內(nèi)容上，我們首先需要與客戶交談。并且，在開始開發(fā)之前，獲取所選用例中的一些錄音樣本，同時預(yù)覽它們或離線工作來估計我們將能夠?qū)崿F(xiàn)的目標并確保它符合客戶的愿景。
開發(fā)人員會犯的一個常見錯誤是在開發(fā)過程中沒有盡早獲得軟件流。這很重要，因為如果我們不盡早進行流式傳輸，我們可能會要處理導(dǎo)致結(jié)果過分承諾的文件。如果我們正在編寫一種算法，它每訪問一位音頻就向數(shù)據(jù)結(jié)構(gòu)添加一個成分，則數(shù)據(jù)結(jié)構(gòu)的大小與我們正在處理的文件的大小成正比。然而，一旦文件被音頻流替換，數(shù)據(jù)結(jié)構(gòu)可能會在設(shè)備運行時無限增大。通過盡早流式傳輸，可以降低開發(fā)風(fēng)險，并且可以進一步確保我們的算法已準備好進行大規(guī)模生產(chǎn)。
另外，從一開始就考慮測試過程。僅通過音頻輸出進行測試很困難，因為它是實數(shù)信號。要確保盡可能多地進行單元測試，而不是依賴于不同處理器和平臺之間可能不同的音頻輸出。
查看編碼過程本身，我們需要在定點和浮點之間做出決定。定點曾經(jīng)是表示用于存儲和計算的音頻樣本的“go to”方法。定點計算將使用與整數(shù)計算相同的ALU部件，一個簡單的數(shù)學(xué)技巧是大致估計連續(xù)變化的數(shù)量，在精度和數(shù)量大小之間進行權(quán)衡。
浮點在ALU中實現(xiàn)起來更復(fù)雜，但在現(xiàn)代CPU中(例如在移動設(shè)備中)使用它幾乎沒有或完全沒有損失。存在的損失被工程時間要求的減少和用于優(yōu)化算法的時間量的增加所抵消。音頻算法通常龐大而復(fù)雜，而浮點可以用更少的工程資源實現(xiàn)它們，因為它簡化了運算。使用浮點數(shù)的開發(fā)人員無需擔(dān)心整數(shù)上溢或下溢。
關(guān)于手機，值得記住的是，手機中通常使用的CPU不僅會處理浮點運算，還會將其矢量化。因此，如果這是我們的用例，請確保我們設(shè)計的代碼能夠進行矢量化。
另一個技巧是在試驗系統(tǒng)行為時將音頻大量寫入文件。根據(jù)我們寫入的介質(zhì)，我們可能需要一個工作線程，例如一張SD卡。這個工作線程就像一個軟件管家，我們可以將音頻數(shù)據(jù)提供給它；它耐心等待，然后將其交給設(shè)備。這意味著我們的核心算法不必等待和阻止運行時的行為。如果要寫入多個文件，請檢查它們是否都從同一位置開始。例如，如果我們停止其中一個文件的開頭40ms，我們會發(fā)現(xiàn)系統(tǒng)中會出現(xiàn)無法解釋的40ms延遲。
在音頻信號處理方面，粗心的人會遇到很多陷阱。但是，通過正確的準備，我們可以通往成功的產(chǎn)品開發(fā)。
(原文刊登于EDN姊妹網(wǎng)站Embedded，參考鏈接：Common mistakes in audio signal processing – and how to avoid them，由Ricardo Xie編譯。)
免責(zé)聲明：本文為轉(zhuǎn)載文章，轉(zhuǎn)載此文目的在于傳遞更多信息，版權(quán)歸原作者所有。本文所用視頻、圖片、文字如涉及作品版權(quán)問題，請聯(lián)系小編進行處理。
推薦閱讀：
面向高功率充放電應(yīng)用的先進電動車電池?zé)峁芾砑夹g(shù)
如何為汽車智能配電系統(tǒng)選擇功率開關(guān)管
