本發(fā)明涉及電子樂器領(lǐng)域，尤其涉及一種用于支持midi協(xié)議的通用樂器音頻數(shù)據(jù)處理系統(tǒng)。

背景技術(shù)：

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

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

3、為此，本發(fā)明提出一種用于支持midi協(xié)議的通用樂器音頻數(shù)據(jù)處理系統(tǒng)。

技術(shù)實現(xiàn)思路

1、本發(fā)明的目的是為了解決現(xiàn)有技術(shù)中存在的缺點，而提出的一種用于支持midi協(xié)議的通用樂器音頻數(shù)據(jù)處理系統(tǒng)。

2、為了實現(xiàn)上述目的，本發(fā)明采用了如下技術(shù)方案：

3、一種用于支持midi協(xié)議的通用樂器音頻數(shù)據(jù)處理系統(tǒng)，包括：

4、環(huán)形緩沖區(qū)模塊，其用于緩存來自中斷或者另一線程的數(shù)據(jù)，作為線程間主要的數(shù)據(jù)交互載體；

5、串口收發(fā)模塊，其通過dma方式接收來自串口總線的數(shù)據(jù)并寫入到接收環(huán)形緩沖區(qū)中，通過信號量激活串口收發(fā)模塊的線程去調(diào)用midi流解碼模塊；讀取發(fā)送環(huán)形緩沖區(qū)的數(shù)據(jù)，通過dma方式發(fā)送到串口總線上；

6、usb收發(fā)模塊，通過usb總線接收或者發(fā)送midi流數(shù)據(jù)；

7、midi流解碼模塊，根據(jù)標準midi協(xié)議解碼midi數(shù)據(jù)流，根據(jù)系統(tǒng)碼類型識別出指令類型及其參數(shù)；

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

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

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

11、發(fā)聲引擎模塊，采用ping-pong雙緩沖模式，將ping緩沖區(qū)中的音頻數(shù)據(jù)通過dma方式輸出到i2s外設(shè)；

12、用戶數(shù)據(jù)存取模塊，用于用戶數(shù)據(jù)的存取；

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

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

15、midi命令發(fā)送模塊，負責管理數(shù)據(jù)幀發(fā)送隊列及命令應答處理；

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

17、優(yōu)選地，所述環(huán)形緩沖區(qū)模塊內(nèi)置有讀信號量機制及寫鎖機制。

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

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

20、優(yōu)選地，所述usb收發(fā)模塊的接收流程為：usb觸發(fā)中斷，中斷程序從接收端點讀取4字節(jié)數(shù)據(jù)，判斷byte0的bit0...3的cin碼以確定后續(xù)有效數(shù)據(jù)長度，將有效數(shù)據(jù)寫入到接收環(huán)形緩沖區(qū)并激活usb收發(fā)模塊線程；

21、所述usb收發(fā)模塊的發(fā)送流程為：當主機端發(fā)起數(shù)據(jù)查詢指令中斷時，中斷程序從發(fā)送環(huán)形緩沖區(qū)讀取最多64字節(jié)數(shù)據(jù)發(fā)送到usb總線上。

22、優(yōu)選地，所述midi流解碼模塊中：

23、若是普通的midi命令就觸發(fā)調(diào)用普通midi命令處理模塊；

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

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

26、優(yōu)選地，所述數(shù)據(jù)存取模塊內(nèi)置有存儲區(qū)塊機制，其將數(shù)據(jù)存取模塊分割為儲存區(qū)塊，每個區(qū)塊存儲一組結(jié)構(gòu)化的用戶數(shù)據(jù)。

27、優(yōu)選地，所述數(shù)據(jù)存取模塊中，每個儲存區(qū)塊包括：

28、head[4]：用于說明本區(qū)塊是什么數(shù)據(jù)；

29、version：當前存儲數(shù)據(jù)的結(jié)構(gòu)體版本；

30、payload_array：要寫入到文件的用戶數(shù)據(jù)結(jié)構(gòu)體的起始地址，也可以是一個結(jié)構(gòu)體數(shù)組；

31、item_size：單個結(jié)構(gòu)體的字節(jié)數(shù)；

32、array_total_size：單個結(jié)構(gòu)體或者結(jié)構(gòu)體數(shù)組的數(shù)據(jù)總大小；

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

34、pos：當是結(jié)構(gòu)體數(shù)組時，是使用default_setting初始化一個或多個數(shù)據(jù)；

35、callback：版本兼容的回調(diào)函數(shù)，當程序請求的結(jié)構(gòu)體的版本與讀取出來的結(jié)構(gòu)體版本不一致時，使用回調(diào)函數(shù)，根據(jù)不同的結(jié)構(gòu)體版本來轉(zhuǎn)換讀取出來的數(shù)據(jù)。

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

37、本發(fā)明的有益效果為：

38、本發(fā)明可以讓應用工程師集中精力關(guān)注于產(chǎn)品功能的開發(fā)，減少對系統(tǒng)框架搭建上的精力投入，大大縮短產(chǎn)品開發(fā)周期，提高設(shè)計效率。

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