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