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

引言

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

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

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

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

3）輸出接口規(guī)范：I2S、DSD；

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

5）適配Windows、Linux系統(tǒng)原生ADC 2.0音頻驅動。

1   基于ADC 2.0規(guī)范的立體聲音頻架構設計

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

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

基于ADC2.0規(guī)范設計功能架構如圖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規(guī)范編寫設備的配置描述符即可定義此架構的邏輯結構，主機通過獲取配置描述符來知曉設備所具有的接口和功能。需要注意的是ADC僅僅提供了一個完整的協(xié)議框架，本身并不實現任何具體功能，開發(fā)者遵循ADC規(guī)范開發(fā)設備和驅動可提高產品和驅動的通用性。

圖1 基于ADC 2.0規(guī)范的音頻接口邏輯架構

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）DMA控制器選擇

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

2）觸發(fā)機制選擇

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

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

3）最大傳輸帶寬計算

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

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

T_S=T_SP+T_SM

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

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

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

2.3 音頻信號的輸出

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

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

2.4 硬件連接框圖

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

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

圖2 硬件連接框圖

3 應用程序框架

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

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

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

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

圖3 播放處理狀態(tài)圖

4 結語

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

圖4 硬件實物圖

設計在以下方面還有進一步研究改進的空間：1、優(yōu)化播放時鐘設計，進一步降低回放失真；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.

（本文來源于《電子產品世界》雜志2020年10月期）