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