本發明涉及電子樂器領域，尤其涉及一種用于支持midi協議的通用樂器音頻數據處理系統。

背景技術：

1、隨著電子樂器功能的不斷發展以及數字音頻工作站daw軟件的普及，更多的daw軟件依賴于midi協議與電子樂器相連，控制電子樂器的發聲、參數設置、業務交互等。由于沒有一個通用的框架，所以開發的時候都是根據產品功能需求從零搭建系統，而且由于大部分的開發工程師(應用工程師)都是來自計算機專業，對樂理、midi協議知識不夠了解，所以在midi編解碼時存在很多條件處理不當導致兼容性不好，系統框架設計不合理或者擴展性差導致難以在不同類型的樂器或者不同平臺復用。

2、在當前的樂器產品芯片及開發方案上，法國廠家dream(dream-audioapplications)提供了一套完整的芯片方案及開發sdk包，尤其是其sam5000系列，開發sdk包已經包含了midi編解碼、midi文件播放、發聲引擎、消息處理框架、硬件驅動等都做好并打包成了庫文件，廠家拿到開發sdk包就可以快速完成產品開發并上市，所以被很多的樂器廠家采用。但由于開發sdk包與芯片硬件深度綁定，無法移植到其它芯片平臺上，且開發sdk包大都是以庫的形式發布，廠家難以從功能上做產品差異化，導致市面上的產品功能雷同且產品功能單一。隨著midi應用的不斷發展，出現了很多的新效果算法、混合效果鏈路等高級應用，但dream芯片的算力、外設資源少、算法開發難度大等原因導致難以滿足新產品應用的需求。同時由于沒有好的人機交互的方式，導致軟件調試不方便，產品到了終端客戶手上后出現問題難以分析原因。而本發明提供的是一個通用的軟件框架及功能代碼的實現，很容易移植到不同的芯片平臺，可以根據產品功能及性能要求自由的裁剪、修改各個模塊。

3、為此，本發明提出一種用于支持midi協議的通用樂器音頻數據處理系統。

技術實現思路

1、本發明的目的是為了解決現有技術中存在的缺點，而提出的一種用于支持midi協議的通用樂器音頻數據處理系統。

2、為了實現上述目的，本發明采用了如下技術方案：

3、一種用于支持midi協議的通用樂器音頻數據處理系統，包括：

4、環形緩沖區模塊，其用于緩存來自中斷或者另一線程的數據，作為線程間主要的數據交互載體；

5、串口收發模塊，其通過dma方式接收來自串口總線的數據并寫入到接收環形緩沖區中，通過信號量激活串口收發模塊的線程去調用midi流解碼模塊；讀取發送環形緩沖區的數據，通過dma方式發送到串口總線上；

6、usb收發模塊，通過usb總線接收或者發送midi流數據；

7、midi流解碼模塊，根據標準midi協議解碼midi數據流，根據系統碼類型識別出指令類型及其參數；

8、普通midi命令處理模塊，處理普通的midi命令，用于控制發聲引擎模塊發出指定的樂器聲音；

9、sysex?midi命令處理模塊，處理私有的通訊協議數據，用于控制設備的工作參數，手機app連接后的業務交互處理；

10、sysex?midi命令處理模塊支持app/上位機通訊協議和藍牙模塊通訊協議；

11、發聲引擎模塊，采用ping-pong雙緩沖模式，將ping緩沖區中的音頻數據通過dma方式輸出到i2s外設；

12、用戶數據存取模塊，用于用戶數據的存取；

13、字符終端模塊，用于接收用戶的輸入指令，完成指令解釋后執行對應的命令處理；

14、midi命令打包模塊，支持對普通midi命令、sysex?midi命令、usb?midi?4字節協議的數據組包處理，并將組包好的數據幀追加到發送等待隊列后激活midi命令發送模塊線程；

15、midi命令發送模塊，負責管理數據幀發送隊列及命令應答處理；

16、業務處理模塊，由應用工程師根據產品功能完成對應的輸入輸出檢測、交互邏輯、業務功能、用戶設置等處理后，生成對應的普通midi碼發送到發聲引擎模塊輸出聲音、調用midi命令打包模塊發送midi協議命令到串口或者usb或者藍牙模塊、通過用戶數據存取模塊讀取或者保存用戶數據到存儲介質、通過字符終端模塊接收調試指令或者輸出調試信息。

17、優選地，所述環形緩沖區模塊內置有讀信號量機制及寫鎖機制。

18、優選地，所述讀信號量機制的邏輯為：線程a在讀取循環緩沖區時，若緩沖區數據為空或者不夠請求的數據量，則線程a將被掛起，cpu資源被釋放；直到緩沖區達到請求的數據量或者超時時間，線程a被重新激活。

19、優選地，所述寫鎖機制的邏輯為：線程b在寫循環緩沖區時將對緩沖區加鎖，若線程c此時也對同一個緩沖區做操作時則被掛起，直到線程b釋放鎖后，線程c才被激活。

20、優選地，所述usb收發模塊的接收流程為：usb觸發中斷，中斷程序從接收端點讀取4字節數據，判斷byte0的bit0...3的cin碼以確定后續有效數據長度，將有效數據寫入到接收環形緩沖區并激活usb收發模塊線程；

21、所述usb收發模塊的發送流程為：當主機端發起數據查詢指令中斷時，中斷程序從發送環形緩沖區讀取最多64字節數據發送到usb總線上。

22、優選地，所述midi流解碼模塊中：

23、若是普通的midi命令就觸發調用普通midi命令處理模塊；

24、若是sysex擴展指令就調用sysex?midi命令處理模塊。

25、優選地，所述發聲引擎模塊的工作邏輯為：當dma完成一次數據傳輸后觸發中斷，將pong緩沖區中的音頻數據通過dma方式輸出到i2s外設，同時往發聲引擎模塊線程發送激活事件以觸發執行一次發聲及效果處理，然后輸出一幀音頻數據到ping緩沖區，如此循環。

26、優選地，所述數據存取模塊內置有存儲區塊機制，其將數據存取模塊分割為儲存區塊，每個區塊存儲一組結構化的用戶數據。

27、優選地，所述數據存取模塊中，每個儲存區塊包括：

28、head[4]：用于說明本區塊是什么數據；

29、version：當前存儲數據的結構體版本；

30、payload_array：要寫入到文件的用戶數據結構體的起始地址，也可以是一個結構體數組；

31、item_size：單個結構體的字節數；

32、array_total_size：單個結構體或者結構體數組的數據總大小；

33、default_setting：指向默認的設置值，當用戶存儲的數據不存在時，可以自動完成初始化；

34、pos：當是結構體數組時，是使用default_setting初始化一個或多個數據；

35、callback：版本兼容的回調函數，當程序請求的結構體的版本與讀取出來的結構體版本不一致時，使用回調函數，根據不同的結構體版本來轉換讀取出來的數據。

36、優選地，所述midi命令發送模塊，如果數據幀為無需應答的話，則直接寫入到發送環形緩沖區并激活串口收發模塊線程或者usb收發模塊線程；如果數據幀需要應答，則需要等待上一條需要應答的指令是否已經完成，只有等待狀態為空才能發送此消息并置為等待應答狀態，當收到應答指令后自動清除應答狀態。

37、本發明的有益效果為：

38、本發明可以讓應用工程師集中精力關注于產品功能的開發，減少對系統框架搭建上的精力投入，大大縮短產品開發周期，提高設計效率。

39、1.同時本發明框架邏輯優異，系統更穩定，大大降低了由應用工程師做不同產品而開發各自的框架時因為個人能力或者考慮不周全導致的程序異常問題，大大減少了測試成本投入，降低產品返修、客戶投訴等風險。