避免音訊訊號處理的常見錯誤

作者 : Dave Betts,AudioTelligence首席科學家

音訊訊號處理產品的設計和編碼軟體有其獨特的挑戰。那麼,開發人員最常犯的錯誤是什麼?如何避免這些錯誤呢?

無論最終產品是什麼,無論使用什麼語言編寫程式碼,世界各地的軟體開發人員都面臨著同樣的挑戰——不斷變化的客戶需求、緊迫的交期、整合和客戶支援,以上只是幾個例子。

但是有一種類型的軟體開發涉及瞭解和解決非常具體的問題。音訊訊號處理產品的設計和編碼軟體有其獨特的挑戰。那麼,開發人員最常犯的錯誤是什麼?如何避免這些錯誤呢?

瞭解訊號處理對於在音訊領域工作的軟體工程師很有幫助,但也並不是必要的。然而,有些領域對音訊有一些瞭解確實有所幫助。

首先,是增益結構,瞭解音量控制可以為系統增加增益。這適用於軟體的內部結構,並將影響插入原型的所有小工具。結果可能是聲音輸出令人不滿意。開發人員以為這是由於程式碼中的錯誤造成的,而實際上這是增益結構的問題。知道這一點可以在不必要的除錯中節省大量時間。

其次,軟體開發人員有時忘記音訊濾波會增加群組延遲。如果忘記了這個基本事實,可能會過份承諾演算法的性能—誤認為它會比實際行動得更快。

第三,另一項重點在於實際資料和理論資料之間的差異。數學有零,但音訊沒有。在數學中,演算法的設計使用理論資料。當使用實際資料測試系統時,可能會發現一個訊號似乎是無聲的。在那種情況下,放大總是值得的——它可能有點嘶嘶聲,也可能全是零。

最後,我們不可能只採用一種演算法並將其部署在所有裝置上。我們需要在開發過程中儘早考慮演算法將要有的部署約束條件。一些DSP非常高效且功耗低,但其記憶體可能有限。其他的可能非常適合用於AI處理,但會引入更高的延遲。如果能設計出一種權衡空間和時間的演算法,那就太好了。但實際上,大多數演算法無法做到這一點,因此我們可能會發現自己無法獲得功耗最低的嵌入式裝置。

在開發開始之前瞭解客戶需求是必不可少的。但在處理音訊時,這一點更重要。為什麼呢?因為對於音訊,客戶不僅需要一個運行良好的系統,還需要一個可以輸出出色音訊的系統。問題是每個人聽到的聲音都不一樣(例如,年齡會影響聽力敏銳度),而且對聽起來「好」的聲音都有個人偏好。我們可能會發現花了很長時間開發的一種產品,最終客戶根本不喜歡。

對於大多數音訊開發人員來說,這是一個持續存在的問題。音訊的評估比視覺演算法的評估更難。這是為什麼?因為視覺結果可以平行放置並同時將其進行比較。但音訊則否:你無法同時聽兩件事。因此,音訊結果的A/B測試只能是循序的,不能同時進行。所以,測試音訊需要更長的時間,我們可能必須聽兩個小時的測試錄音僅僅是為了評估對演算法的小幅調整。因此,確保專案計畫包含的測試時間比認定所需的時間更長。

透過商定使用一種普遍被接受的音訊測試指標(例如MOS分數)來避免這種主觀性。這些輸入於音訊中並預期觀眾對結果的評價。它確實有助於評估品質,但無法提供改進的原因。許多常見的測試和指標是為有線電話等傳統的現有應用開發的,並且偏向於這些應用。因此,使用指標會有所幫助,但這不是絕對的答案。在開始工作之前,必須確保客戶分享其願景,畢竟客戶希望音訊聽起來像什麼才重要。

瞭解客戶的願景對於下一個要注意的問題整合也很重要。音訊是系統的一部份。所有部份都必須協同工作,但系統的其餘部份受處理音訊的消耗限制,而音訊也受系統其餘部份消耗的限制。如果音訊在實際的系統上斷斷續續,那麼在空的系統上開發運行良好的東西是沒有意義的,而且會浪費很多資源。所以,早點整合吧!但是,正如開發人員所知,整合的成本很高。為了防止將時間浪費在整合不合適的內容上,首先需要與客戶討論。並且,在開始開發之前,獲取所選用例中的一些錄音樣本,同時預覽它們或離線工作來估計能夠實現的目標並確保符合客戶的願景。

開發人員會犯的一個常見錯誤是在開發過程中未能儘早獲得軟體串流。這很重要,因為如果不儘早進行資料串流,可能必須處理導致結果過份承諾的檔案。如果我們正在編寫一種演算法,它每存取一位元音訊就向資料結構添加一個成份,則資料結構的大小與我們正處理中的檔案大小成正比。然而,一旦檔案被音訊串流替換,資料結構可能會在裝置運行時無限增大。透過儘早串流資料,可以降低開發風險,並進一步確保演算法已準備好進行大規模生產。

另外,從一開始就考慮測試過程。僅透過音訊輸出進行測試很困難,因為它是實數訊號。為了確保盡可能多地進行單元測試,而不是依賴於不同處理器和平台之間可能不同的音訊輸出。

查看編碼過程本身,必須在定點和浮點之間做出決定。定點曾經是表示用於儲存和計算的音訊樣本的“go to”方法。定點計算將使用與整數計算相同的ALU部件,一個簡單的數學技巧是大致估計連續變化的數量,在精度和數量大小之間進行權衡。

浮點在ALU中實現起來更複雜,但在現代CPU中(例如在行動裝置中)使用它幾乎沒有或完全沒有損失。存在的損失被工程時間要求的減少和用於最佳化演算法的時間量的增加所抵消。音訊演算法通常龐大而複雜,而浮點可以用更少的工程資源來實現,因為它簡化了運算。使用浮點數的開發人員無需擔心整數上溢或下溢。

關於手機,值得記住的是,手機中通常使用的CPU不僅會處理浮點運算,還會將其向量化。因此,如果這是我們的用例,請確保設計的程式碼能夠進行向量化。

另一個技巧是在試驗系統行為時將音訊大量寫入檔案。根據寫入的介質,我們可能需要一個工作執行緒,例如一張SD卡。這個工作執行緒就像一個軟體管家,可以將音訊資料提供給它;讓它耐心等待,然後將其交給裝置。這意味著核心演算法不必等待和阻止運行時的行為。如果要寫入多個檔案,請檢查它們是否都從同一位置開始。例如,如果停止其中一個檔案的開頭40ms,我們會發現系統中會出現無法解釋的40ms延遲。

在音訊訊號處理方面,粗心的人會遇到很多陷阱。但是,只要有完全的準備,就能夠成功的開發產品。

編譯:Ricardo Xie

(參考原文:Common mistakes in audio signal processing – and how to avoid them,by Dave Betts)

活動簡介

目前寬能隙(WBG)半導體的發展仍相當火熱,是由於經過近幾年市場證明,寬能隙半導體能確實提升各應用系統的能源轉換效率,尤其是應用系統走向高壓此一趨勢,更是需要寬能隙元件才能進一步提升能效,對實現節能環保,有相當大的助益。因此,各家業者也紛紛精進自身技術,並加大投資力道,提升寬能隙元件的產能,以因應市場所需。

本研討會將邀請寬能隙半導體元件關鍵供應商與供應鏈上下游廠商,一同探討寬能隙半導體最新技術與應用市場進展,以及業者佈局市場的策略。

贊助廠商

加入LINE@,最新消息一手掌握!

發表評論