基於STM32F4和CPLD的高品質立體聲USB數字音頻接口設計

本文引用地址：http://www.eepw.com.cn/article/202010/419295.htm

引言

在高品質音頻回放系統中，USB協議[1]被廣泛應用於音頻數據的傳輸。目前高品質音頻設備大多基於USB Audio Devices Class（以下簡稱ADC）2.0規範[2]開發USB音頻接口。當前較為常見的USB音頻接口方案的核心晶片有如下以下幾種選擇：1、專用USB音頻接口晶片；2、XMOS系列晶片；3、帶有USB2.0模塊的通用單片機；4、FPGA晶片。從產品成本和生命周期考慮，產品方案中核心晶片應該選擇市場上佔有率大產品線成熟產品支持完善且價格相對低廉的型號。專用晶片底層不透明適用範圍窄難以根據需求進行個性化開發，XMOS晶片產品支持較少開發文檔不豐富，FPGA晶片開發難度和成本較高。通用單片機是一個較好的選擇，但通用單片機的數字音頻輸出功能通常較薄弱需要對其進行一定的擴充。本文基於市場上應用廣泛的STM32F4晶片和CPLD晶片設計了一款高性能USB數字音頻接口。

本文所設計音頻接口指標和特性如下：

1）支持的音頻數據流格式：16bit PCM、32bit PCM、DoP(DSD Audio over PCM Frames)、NativeDSD；

2）支持的最高數據規格：384kHz PCM、DSD256；

3）輸出接口規範：I2S、DSD；

4）異步反饋模式，主機時鐘與設備時鐘完全解耦，數字輸出信號質量可控；

5）適配Windows、Linux系統原生ADC 2.0音頻驅動。

1   基於ADC 2.0規範的立體聲音頻架構設計

ADC 2.0規範相較於其1.0版本架構更複雜包含的內容更為豐富，也增加了開發的難度。ADC 2.0物理層面上基於USB 2.0協議，完全支持高速USB傳輸，帶寬不再受限。邏輯層面上，ADC 2.0規範為儘可能滿足不同的音頻數據傳輸需求，規定了一套較為複雜的抽象層邏輯。其中USB音頻功能通過定義完善的接口來實現與外部的連通。每個音頻功能都必須包含一個音頻控制接口和可選的音頻流接口。音頻控制接口用於訪問對應的音頻功能，音頻流接口用於傳輸音頻數據。

為有效操地操作各種音頻功能，ADC規範將其分割為不同的實體，依據功能特徵實體可分為三大類：單元、埠、時鐘。音頻設備通過設備描述符定義音頻控制接口、音頻流接口和功能實體並將其從邏輯上串接在一起向主機描述設備所能實現的邏輯行為。

基於ADC2.0規範設計功能架構如圖1所示。

1）Audio Streaming Interface定義了主機到設備的數據傳輸接口。該接口有3個備選接口設置分別用於傳輸32bit PCM、16bit PCM和NativeDSD數據。

2）Audio Control Interface定義了主機到設備的控制接口，該接口下包含了用於傳輸音頻數據和實現部分功能的實體，主機通過設備請求來訪問不同實體的具體功能。ID1是input terminal用於接收USB數據流也定義了輸出聲道的數量；ID2是output terminal相當於一個消耗USB數據的終端，主機一般需要結合audio streaming接口和端點描述符來確定此終端的具體特徵行為；ID3是feature unit使能了音量控制和靜音控制；ID4、ID5是clock source，用於描述時鐘特徵；ID6是clock selector，用於選擇時鐘信號的連接方式。

依據ADC規範編寫設備的配置描述符即可定義此架構的邏輯結構，主機通過獲取配置描述符來知曉設備所具有的接口和功能。需要注意的是ADC僅僅提供了一個完整的協議框架，本身並不實現任何具體功能，開發者遵循ADC規範開發設備和驅動可提高產品和驅動的通用性。

圖1 基於ADC 2.0規範的音頻接口邏輯架構

2 基於STM32F4 的USB Audio Class設備設計

由於ADC2.0規範是基於USB2.0協議的^[2]，需要設備具有高速傳輸能力。STM32F4的高速USB OTG模塊沒有片上高速PHY，只有UPLI接口，因此需要外接USB UPLI晶片來實現高速USB功能。本設計採用了較為常用的USB3300晶片與STM32F4連接，STM32F4提供完整的UPLI協議硬體支持^[3]，只需要操作對應的寄存器即可實現相應的通信功能，不需要過多關注USB控制器具體底層的操作，大大降低了程序設計難度。

2.1 音頻數據傳輸和頻率反饋控制

依據ADC規範，設備需要使用等時端點來傳輸音頻數據。由於主機和設備的時鐘存在頻率誤差、相位誤差和相位抖動，為保證音頻數據傳輸的完整連貫性，必須在主機和設備間建立一種同步機制。USB協議針對等時傳輸提供了三種同步方案[1]，以設備角度來分析如下

1）將設備時鐘同步到主機SOF（幀起始）信號上；

2）設備根據主機發送數據的速率調整數據消耗速率；

3）設備和主機獨立運行在自己的時鐘上，設備提供時鐘速度的顯式反饋。

方案1）音頻回放質量依賴於主機時鐘質量和頻率跟蹤誤差，方案2）設備為保持同步必須在軟體裡動態調節回放頻率直接造成失真。只有方案3）才能完全消除主機和設備間的時鐘耦合，這是高品質回放的必要條件。

在一般音頻驅動程序中，主機使用EP1 _OUT端點來傳輸音頻數據，使用EP1 IN端點來進行傳輸頻率的反饋。當播放開始後，主機每個微幀都會向EP1發送音頻數據，主機每4微幀向EP1請求一次4位元組的IN傳輸。IN傳輸返回的數據是一個頻率參數，主機根據此參數動態地調整每個微幀發送的數據幀數量從而調節數據發送速率。

由於主機和設備獨立運行在各自的時鐘源上，因此主機發送數據頻率和設備消耗數據頻率不可能完全一致，如果不進行處理會出現數據溢出和丟失問題。解決方案是在設備程序中設計一個緩衝區暫存數據，根據緩衝區長度向主機發送需要的數據速率來進行滯環控制，從而實現對緩衝區數據長度的跟蹤。環寬和跟蹤目標的選擇需結合主機和設備時鐘的最大可能誤差以及控制晶片允許的存儲空間來確定。依據USB 2.0協議，高速傳輸的比特率精度應控制在500ppm(0.05%)以內，設環寬為，數據速率為則。

因主機傳輸數據以微幀為單位，設每個微幀內可能傳輸的最大數據量為字節，為防止數據上溢或下溢，追蹤數據長度應大於。

2.2 音頻輸出接口與STM32F4間的通信實現

由於STM32F4晶片自身音頻接口功能有限，且不能直接輸出DSD信號，所以只能考慮駁接外部晶片來實現設計目標。這部分功能主要是完成音頻信號時序輸出，因此選用CPLD晶片較為合理。

從主機接收的USB音頻數據在STM32F4晶片中處理後輸出到CPLD晶片，二者之間需要一個傳輸的通道。本設計最高數據規格是PCM 32bit/384kHz，計算可得數據帶寬為24.576Mbit/s，由參考手冊^[3]可知SPI1通道與高速USB接口復用無法使用其SPI功能，而其它SPI通道最高速率為21Mbit/s無法滿足設計要求。因此需用並行傳輸來提高接口帶寬，由於音頻數據量大且對實時性要求很高，不宜直接通過操作IO口來輸出數據，考慮使用STM32的DMA功能來實現並行傳輸。

得益於STM32F4的DMA IP核基於多層總線矩陣的設計，可以利用DMA和GPIO埠進行並行同步傳輸，其本質原理是利用某種觸發機制實現數據從SRAM到GPIO的DMA傳輸^[4]。

1）DMA控制器選擇

STM32F4片上集成2個DMA IP。每個DMA各有一個存儲器埠和一個外設埠。利用外部總線矩陣和專用DMA路徑，不僅在DMA級兩個埠可以同時工作，還可以實現DMA和系統其它主設備同時工作。GPIO位於AHB1總線上，由參考手冊[3]可知STM32F4的DMA1的AHB外設埠沒有連接到總線矩陣，因此只有DMA2可實現從SRAM到AHB1外設的訪問。

2）觸發機制選擇

同步傳輸根據同步信號的提供者可將設備分為主從兩方。本文以STM32F4作為從設備，CLPD作為主設備進行設計。CLPD向STM32發出同步信號來請求數據，當STM32接收到一個合法的觸發信號應觸發一次DMA傳輸，將存儲器（源地址）上的數據由DMA控制器傳輸到GPIO（目標地址）上。這裡就需要一個外設來接收並處理外部觸發信號並產生DMA請求，顯然定時器模塊很適合完成這項工作。

由參考手冊^[3]可知只有兩個高級控制定時器TIM1和TIM8可以產生DMA2的請求，但可產生DMA請求的事件比較豐富，本設計選擇了TRIG事件來觸發DMA請求。具體實現方法是將定時器設置為外部時鐘觸發模式，選擇一個GPIO埠x的上升沿觸發TRIG事件，每當CPLD在埠x處產生一個上升沿信號即觸發DMA傳輸請求，數據從預設的地址傳輸到GPIO埠上，CPLD即可從相應埠並行地讀入取此數據。

3）最大傳輸帶寬計算

此設計中影響STM32F4到CPLD傳輸帶寬的因素主要有DMA傳輸時間、定時器收入捕獲數字濾波時間和CPLD埠建立時間。由於CPLD埠建立時間較短，此處不予考慮。

本設計DMA設置是從存儲器傳輸數據到AHB外設，使用突發傳輸，不需要進行總線仲裁，則DMA數據流的總傳輸時間為：

T_S=T_SP+T_SM

其中是DMA外設埠訪問和傳輸的總時間，T_SM是DMA存儲器埠訪問和傳輸的總時間。依據參考文獻[5]計算可得，最壞情況下DMA傳輸時間為8個AHB周期。

定時器輸入捕獲數字濾波器是為了消除幹擾引起的誤觸發，數字濾波器由事件計數器組成，每N個事件才視為一個有效邊沿，將其設置為連續4個AHB周期。則從CPLD給出上升沿觸發信號到CPLD讀取到數據的延時為12個AHB周期。將AHB頻率設置為84MHz，在用8位GPIO口並行輸出的情況下，接口帶寬為：

可見傳輸帶寬完全滿足設計需要。若使用整組16位GPIO做輸出可降低晶片主時鐘頻率且為帶寬留出較大裕度，為設備功能升級留有裕量。

2.3 音頻信號的輸出

本設計中，PCM音頻信號輸出採用I2S接口，DSD音頻信號輸出由DSD時鐘信號和DSD左右聲道數據信號構成^[6]。

對於PCM數據，主機傳入設備的數據是低字節在前高字節在後，而I2S協議是從數據高字節開始串行輸出的；對於DSD數據而言主機整幀的傳入數據而在信號輸出端左右聲道卻是同時輸出的。因此設備需要對原始數據進行重新組合處理。CPLD門資源較為有限，為降低片上資源的使用率和綜合布線難度，處理數據的工作全部由STM32晶片負責。CPLD依據前述設計方案從STM32緩衝區依次並行讀取數據再將數據按各播放模式的時序邏輯串行輸出即可。

2.4 硬體連接框圖

設備的主要硬體連接框圖如圖2所示。STM32通過ULPI PHY晶片與主機通信，與CPLD相連接的信號中CMD為控制信號，本設計使用SPI總線向CPLD發送控制指令。RDY為程序通知CLPD可以進行數據請求的信號。REQ為CPLD向STM32發送的數據請求信號，此信號即用於觸發DMA請求。DATA為並行的數據信號。CPLD向外輸出I2S和DSD時序信號，外部控制晶片可通過AUX接口來讀取設備的相關狀態。

主機時鐘源1和負責提供回放時鐘的時鐘源2相互獨立，因此時鐘源2可以選用低相位噪聲的時鐘來提升音頻回放質量。

圖2 硬體連接框圖

3 應用程式框架

由於基於上述設計方案的軟體實現方案非常靈活，部分技術雖為通用技術但細節又較為繁瑣，本節僅對一種可行性方案概括性說明。

此方案主要由三個模塊構成：USB底層通信程序、Setup傳輸處理程序、播放處理程序。具體功能使用了三個狀態機實現，由於USB通信程序中包含了硬體中斷，三個狀態機之間的通信由消息隊列來實現異步通信。此處不對USB底層通信和Setup傳輸處理程序進行贅述，重點對播放處理的狀態機設計進行說明。

基於上述原理設計的播放處理狀態機的UML狀態圖如圖3所示，整個播放過程在播放監控狀態中運行，在PlayGuard_IDLE狀態中程序接收相關的參數設置信號為播放做準備。PlayGuard_PLAYING是一個組合狀態，其自身負責與USB底層模塊通信進行數據傳輸，其子狀態負責處理特定播放模式。

音頻數據的流轉是程序的核心算法。音頻數據通過OUT傳輸寫入程序緩衝區，數據由播放子狀態處理並寫入FIFO中。程序將DMA傳輸設置為雙緩衝模式，在DMA完成事件中從FIFO讀出一組數據對雙緩衝區進行交替填充。在IN傳輸完成事件中計算當前FIFO區數據長度據此反饋數據傳輸率給主機完成對數據長度的追蹤控制。

圖3 播放處理狀態圖

4 結語

基於上述設計製作了硬體實物如圖4，分別在Windows 10系統和Linux發行版下進行測試實驗，接口板在系統原生驅動下工作正常，可播放所支持規格的PCM音頻文件。在三方驅動下可正常通過DoP模式或NativeDSD模式播放DSD音頻文件。播放自定義音頻文件並用邏輯分析採集輸出接口的數據與源文件對比，接口板完整無失真的還原了源文件的數據。在軟體開發平臺上對緩衝隊列進行監控，程序能較好的跟蹤隊列長度的穩定，無數據溢出現象。最後將接口板連接至解碼器上進行試聽，主觀聽感良好。以上試驗證明設計達到了預期指標。

圖4 硬體實物圖

設計在以下方面還有進一步研究改進的空間：1、優化播放時鐘設計，進一步降低回放失真；2、增加對更多聲道音頻格式的支持；3、增加數字音效的功能；4、增加Bootloader程序，實現主機對設備功能和參數的在線升級與修改。

參考文獻

[1] Universal Serial Bus Specification[EB/OL]. Revision 2.0, USB-IF,(2000-4-27)[2020-4-25].https://www.usb.org.

[2] Universal Serial Bus Device Class Definition for Audio Devices[EB/OL]. Release 2.0,USB-IF, (2006-5-31)[2020-4-25].https://www.usb.org.

[3] STM32F405/415, STM32F407/417, STM32F427/437 and STM32F429/439 advanced Arm®-based 32-bit  MCUs Reference manual (RM0090)[EB/OL]. Rev 18, STMicroelectronics, (2019)[2020-4-25].https://www.st.com.

[4] Parallel synchronous transmission using GPIO and DMA(AN4666)[EB/OL]. Rev 1, STMicroelectronics, (2016)[2020-4-25].https://www.st.com.

[5] Using the STM32F2, STM32F4 and STM32F7 Series DMA controller(AN4031)[EB/OL]. Rev 3, STMicroelectronics, (2016)[2020-4-25].https://www.st.com.

[6] J. ROBERT STUART. Coding for High-Resolution Audio Systems[J]. Audio Eng. Soc., 2004,Vol. 52, No. 3:117-144.