新聞中心

EEPW首頁 > 消費電子 > 設(shè)計應(yīng)用 > 利用實時Java設(shè)計數(shù)字音頻系統(tǒng)

利用實時Java設(shè)計數(shù)字音頻系統(tǒng)

作者: 時間:2008-05-26 來源:網(wǎng)絡(luò) 收藏
在傳統(tǒng)的信息技術(shù)領(lǐng)域,已成為首選的編程語言,因為它能提高開發(fā)者的生產(chǎn)率、軟件復(fù)用率和可靠性,降低軟件維護成本,并提供更靈活、更通用的軟件結(jié)構(gòu)。

如今,在低級、硬件、軟件領(lǐng)域已有各種各樣的方案。但是,當(dāng)在像信號處理這樣非常低級的軟件中應(yīng)用技術(shù)時,某些方案將更能發(fā)揮傳統(tǒng)Java技術(shù)的優(yōu)越性。

其中一種方法基于針對資源受限和安全關(guān)鍵的Java定義的推薦規(guī)范。該方案的主要目的是保持Java的可移植性、可維護性和可擴展性優(yōu)勢。在內(nèi)的信息流中包括兩臺計算機,這兩臺計算機協(xié)同操作以便通過網(wǎng)絡(luò)通訊通道交換信息(圖1)。

在一個節(jié)點上采集到的信號被傳輸至其它節(jié)點,并被輸出至遠(yuǎn)程計算機的揚聲器。在第二個節(jié)點上采集到的音頻信號則在第一臺計算機的揚聲器中輸出。從概念上講,信息流被構(gòu)造成兩個獨立的音頻數(shù)據(jù)流。

這種簡單的音頻處理應(yīng)用可以被當(dāng)作PERCPico應(yīng)用程序來實現(xiàn)。該軟件目前正在開發(fā)中,它首次實現(xiàn)了針對安全關(guān)鍵和資源受限應(yīng)用所提出的Java(RTSJ)規(guī)范概要分析?!坝?a class="contentlabel" href="http://butianyuan.cn/news/listbylabel/label/實時">實時概要分析(hardreal-timeprofile)”即指這種環(huán)境。

圖1:一個簡單的音頻應(yīng)用構(gòu)成了本文討論的關(guān)鍵性軟件工程的基礎(chǔ)。

維護和可擴展性要求

摩爾定律推動了典型嵌入式應(yīng)用的規(guī)模和復(fù)雜度快速增長。競爭壓力促使軟件不斷發(fā)展,以滿足功能越來越強大的硬件的需求。對某些消費電子設(shè)備的研究發(fā)現(xiàn),新產(chǎn)品中代碼規(guī)模的增長速度非常接近摩爾定律,大約每18至36個月就翻一番。

大約20年前,每個新的嵌入式設(shè)備中的所有軟件通常是由一個或兩個工程師在不到一年的時間內(nèi)寫完。而現(xiàn)代嵌入式軟件的開發(fā)則非常困難。假設(shè)每次新產(chǎn)品的軟件修訂都要求增加數(shù)十萬,甚至數(shù)百萬行的代碼,那么嵌入式軟件開發(fā)人員的職責(zé)將更多地轉(zhuǎn)向如何解決集成許多獨立開發(fā)的軟件組件所帶來的挑戰(zhàn)。

這個簡單的數(shù)字音頻例子代表了一種原型的低級嵌入式軟件“產(chǎn)品”。對大多數(shù)產(chǎn)品而言,開發(fā)原始軟件的成本要比整個產(chǎn)品生命周期內(nèi)的軟件維護成本小得多。以下列出了該應(yīng)用在產(chǎn)品生命周期內(nèi)的發(fā)展過程。

(1)軟件將需要被移植到不同的操作和不同的處理平臺上,這將改變它的CPU時間和內(nèi)存需求。

(2)軟件將與各種不同的補充功能集成在一起。也許下一代產(chǎn)品也將包括視頻信號。也許它將支持共享數(shù)字白板,以便于召開遠(yuǎn)程會議,或者可能與電子郵件和日歷軟件集成在一起。或者,一些應(yīng)用可能增加錄制功能,以將會議實況保存在磁盤中。

(3)雙節(jié)點網(wǎng)絡(luò)拓?fù)淇赡苄枰M行通用化,以支持有任意多參加者的會議。

(4)模數(shù)轉(zhuǎn)換器(ADC)和數(shù)字信號處理器(DSP)的接口可以不斷發(fā)展。在一些配置中,操作提供了這種服務(wù)。而在其它配置中,這種應(yīng)用可能包括連接音頻子系統(tǒng)硬件和DMA內(nèi)存設(shè)備的設(shè)備驅(qū)動程序接口。音頻硬件本身有望繼續(xù)發(fā)展,這要求軟件設(shè)備驅(qū)動程序不斷發(fā)展。

(5)網(wǎng)絡(luò)通信協(xié)議可能需要作一些改變。在某些環(huán)境中,軟件將依賴底層操作系統(tǒng)服務(wù)來與網(wǎng)絡(luò)連接。隨著各種網(wǎng)絡(luò)通信協(xié)議的發(fā)展,連接操作系統(tǒng)網(wǎng)絡(luò)業(yè)務(wù)的接口甚至也可能發(fā)生變化,以便提供新的QoS參數(shù)和更高帶寬。在其它情況下,這種應(yīng)用將需要包含面向硬件接口的低級設(shè)備驅(qū)動程序,也可能需要實現(xiàn)通信協(xié)議棧。可以采用帶沖突檢測的載波偵聽多路訪問(CSMA/CD)技術(shù)、無線、光纖和其它有待發(fā)明的技術(shù),在低成本專用串行通道、同軸電纜和雙絞線數(shù)據(jù)鏈接中實現(xiàn)相同的基礎(chǔ)通信能力。通信庫可能集成了壓縮、加密、檢錯和糾錯,以及滑動窗口協(xié)議。

上面給出了軟件在商業(yè)化業(yè)務(wù)應(yīng)用中的幾種可能發(fā)展方式,這里并非想窮舉所有的優(yōu)勢,只是為了說明保留Java優(yōu)勢的好處,即使是對于一些資源受限和硬實時應(yīng)用來說。

圖2:硬實時JAVA翻譯環(huán)境顯示了各種工具之間的關(guān)系,這些工具可使實時組件的開發(fā)、維護和集成更容易。

實時JAVA的能力

這些實時Java編程技術(shù)由RTSJ衍生發(fā)展而來。該規(guī)范具有很好通用性,能支持多種獨特的實時編程要求。由于本文主要關(guān)注非常低級的實時軟件,所以我們將開發(fā)人員的操作限定在完整RTSJ規(guī)范的子集范疇內(nèi)。

這種概要分析可改善可移植性、可靠性和效率,因為它禁止使用一些需要很大的運行時間開銷、會帶來不可移植的實現(xiàn)依賴性、增加軟件復(fù)雜度以致使程序員更容易出錯的功能。硬實時概要分析和完整RTSJ之間一些特殊差異包括:

(1)完整的RTSJ對同步鎖采用優(yōu)先級繼承方法,并支持優(yōu)先級限高仿真可選。硬實時概要分析禁止使用優(yōu)先級繼承并要求支持優(yōu)先級限高仿真。

(2)完整的RTSJ允許即時修改各種線程調(diào)度和對象同步參數(shù)。硬實時概要分析禁止對線程調(diào)度和同步協(xié)議進行即時調(diào)整。

(3)完整的RTSJ還支持一些機制,這樣每當(dāng)任務(wù)錯過最終期限或超出其CPU時限時,就可以自動觸發(fā)異步事件。請注意,這些服務(wù)的實現(xiàn)是完全不可移植的,而精確執(zhí)行會帶來極高的運行時間開銷。此外,在硬實時應(yīng)用中不需要運行時間限制,因為在程序執(zhí)行之前,已經(jīng)靜態(tài)地滿足資源預(yù)算和最終期限要求。因此,硬實時概要分析不支持這些機制。

(4)完整的RTSJ支持傳統(tǒng)線程、訪問垃圾收集堆的實時線程,以及不訪問垃圾收集堆的實時線程的混合體。這種不同線程類型的混合大大增加了系統(tǒng)的復(fù)雜度和規(guī)模。這種復(fù)雜度將增加由于不同線程類型之間不能正確共享信息而導(dǎo)致的實時編程出錯的可能性,硬實時概要分析僅支持不訪問垃圾收集堆的實時線程。

(5)完整的RTSJ提供一系列可供應(yīng)用程序員使用的庫,以便舉例說明動態(tài)內(nèi)存范圍,并在特定范圍內(nèi)分配對象。由于程序員在開發(fā)或集成采用嵌套作用域(nested scope)的組件時可能會產(chǎn)生許多小錯誤,所以這些庫的使用尤其成問題。為執(zhí)行正確的區(qū)域性存儲器(scoped-memory)使用協(xié)議,RTSJ在每次讀取和/或重寫參考字段時都執(zhí)行特殊的運行時檢查。在完整的RTSJ中,運行時進行檢查會使程序組件出錯,從而使得程序由于非法分配、非法讀取、區(qū)域性存儲器協(xié)議錯誤、內(nèi)存不足錯誤等原因,以運行時間異常方式終止執(zhí)行。硬實時概要分析禁止使用RTSJ內(nèi)存作用域(memory scope)操作庫。相反,它要求程序員以編程注釋的形式描述其對作用域內(nèi)存(scoped-memory)的使用。在編譯期間,這些注釋可以被分析和執(zhí)行,例如本文應(yīng)用提到的@Scoped和@StaticAnalyzable注釋。

(6)RTSJ不會為了中斷處理或低級設(shè)備的I/O而對庫進行標(biāo)準(zhǔn)化,而硬實時概要分析對這些庫進行定義。

硬實時概要分析的商用化前實現(xiàn)試驗顯示,它運行在某些CPU密集型基準(zhǔn)程序的速度比標(biāo)準(zhǔn)Java和完整RTSJ的速度快三倍。這是因為硬實時執(zhí)行環(huán)境比標(biāo)準(zhǔn)RTSJ簡單得多,并且它還用編譯時間驗證替代各種運行時檢查。這種性能可以與相應(yīng)的C和C++程序相媲美,有時甚至更好。

盡管采用受限的硬實時概要分析比采用傳統(tǒng)Java更加困難,但這種平臺的代碼開發(fā)和維護要比用C或C++開發(fā)出的相應(yīng)平臺的維護容易。這是因為硬實時Java平臺具有更好的可移植性,并提供高級的面向?qū)ο蟮某橄?。此外,硬實時Java平臺包括可使實時組件的開發(fā)、維護和集成更為容易的一些重要開發(fā)工具(圖2)。

由于包含了強制嚴(yán)格遵守類型安全的字節(jié)碼校驗器,與C和C++相比,Java開發(fā)可提高可靠性和可維護性。C和C++程序員可以多種讓使類型安全無效的機制,而有意或無意地這些漏洞將使代碼更容易產(chǎn)生錯誤,并降低可移植性。

受限的實時環(huán)境提供了比傳統(tǒng)Java更嚴(yán)格的字節(jié)碼驗證。特別是,圖2中的硬實時驗證器可確保指向堆棧分配對象的參數(shù)(指針)不會比對象本身的生存期更長。它也確保用專用@StaticAnalyzable注釋標(biāo)記的程序組件,可限制它們對可分析子集使用Java。與硬實時翻譯器的集成,則能提供確定執(zhí)行每個組件所需的CPU時間和堆棧內(nèi)存上限的能力。

執(zhí)行硬實時組件所需的所有臨時內(nèi)存分配,必須由正在執(zhí)行線程的運行時棧來實現(xiàn)。執(zhí)行從單主線程開始,而主線程的運行時棧代表了所有可重復(fù)使用的內(nèi)存。對于由主線程派生的每個附加線程,它提供了部分運行時棧作為派生線程的運行時棧。

圖3:該模塊圖說明了SimpleAudio數(shù)字音頻應(yīng)用的體系結(jié)構(gòu)。


數(shù)據(jù)音頻應(yīng)用的實現(xiàn)

圖3給出了數(shù)字音頻應(yīng)用的體系結(jié)構(gòu)。它共有6個線程,包括主線程和用Orchestrator實例表示的異步事件處理器。BufferPair將每個插座接口連接至相應(yīng)的DSP接口。主線程監(jiān)控用戶指令,并在用戶請求關(guān)閉會話時調(diào)用SimpleAudio實例的terminateActivity()方法。所有其它線程通過調(diào)用continueActivity()業(yè)務(wù),定期輪詢SimpleAudio實例。到了關(guān)機時,該方法返回false值。

在缺省配置中,該應(yīng)用以8kHz采樣頻率對麥克風(fēng)輸入進行采樣,每次采樣采集8比特數(shù)據(jù)。這種配置每秒鐘產(chǎn)生8k字節(jié)的數(shù)字音頻數(shù)據(jù),這對簡單的語音應(yīng)用來說已經(jīng)足夠。但是,它不適合高保真立體聲信號。一般的CD錄制以44.1kHz的采樣頻率對兩個立體聲信道每次采樣16比特。這種高保真度信號的帶寬要求為176.4千字節(jié)/秒。

在缺省配置中,插槽讀模塊和寫模塊采用足夠的帶寬進行可靠傳輸,以可靠提供所有從DSPReader模塊采集的數(shù)據(jù)。我們采用了一種直接壓縮技術(shù),一連串同樣的字節(jié)值(像出現(xiàn)在靜音期間的那樣)由一個專用的轉(zhuǎn)義(escape)值、重復(fù)次數(shù)和重復(fù)值表示。當(dāng)然,更先進的壓縮技術(shù)將更為合適。

在實時系統(tǒng)中,由抖動描述特定實時組件的理想執(zhí)行時間的預(yù)期偏離,由一個確切的線程描述數(shù)字音頻應(yīng)用的每個組件。SocketWriter線程接收來自DSPReader模塊的原始數(shù)據(jù)流,對數(shù)據(jù)進行壓縮,并將數(shù)據(jù)傳送至網(wǎng)絡(luò)插座通道。如果網(wǎng)絡(luò)插座通道的帶寬有限,只能達(dá)到預(yù)算的8千字節(jié)/秒,那么任何導(dǎo)致SocketWriter延遲數(shù)據(jù)傳輸?shù)亩秳佑绊憣㈦S著時間而累積。

在缺省配置中,預(yù)計SocketWriter每125µs傳輸1字節(jié)數(shù)據(jù)。如果每秒的音頻數(shù)據(jù)有1個字節(jié)延遲半毫秒,則1小時后,累積延遲將約為2秒。為防止抖動延遲的累積,該架構(gòu)包含一個運行在16Hz的監(jiān)視線程。

在每個周期內(nèi),該線程強制讓SocketWriter和DSPWriter組件丟棄62.5ms之前的數(shù)據(jù)。由于我們處理的是音頻數(shù)據(jù),所以通常來講,丟棄的臨時數(shù)據(jù)值比允許數(shù)據(jù)到達(dá)時間偏移更可取一些。人們通常不會注意到丟棄臨時數(shù)據(jù)字節(jié)的影響。

請注意在第1行出現(xiàn)的@StaticAnalyzable注釋,源碼列表中的@ StaticAnalyzable(enforce_time_analysis = {false}, enforce_non_blocking = {false})。這代表了部分方法簽名(method signature)。注意該注釋給出了enforce_time_analysis 和enforce_non_blocking屬性的參數(shù)值,兩者都是false。這表示該方法的實現(xiàn)無需將其本身限制在子集內(nèi),對于該子集,靜態(tài)分析器可從中推斷執(zhí)行該方法所需要的嚴(yán)格CPU時間上限,也不要求靜態(tài)分析器驗證該方法執(zhí)行時永遠(yuǎn)不會阻斷。

如果這些屬性定義沒有給出,硬實時驗證器將認(rèn)為程序不合法,因為在源碼列表的(!orchestrator.destroy()) { through 57, }執(zhí)行時,靜態(tài)分析器無法確定該循環(huán)包含了多少次第55行。此外,main方法的執(zhí)行可能會在第59行的socket_ reader_thread.join()至63行的orchestrator_thread.join()之間阻斷,以及在第51行sa.awaitTermination()調(diào)用的await-Termination()方法中阻斷。

在@StaticAnalyzable注釋中未注明的是enforce_memory_analysis屬性的值。該屬性的缺省值為true,這意味著該方法的實現(xiàn)必須符合限定的指導(dǎo)方針以使執(zhí)行該方法時靜態(tài)分析器能夠確定將要分配的最大內(nèi)存。假設(shè)該環(huán)境的實時Java規(guī)則將內(nèi)存作為運行棧的一部分,則臨時內(nèi)存分配的上限就表示必需的主線程的運行時棧大小。

注釋有助于軟件開發(fā),并大大簡化軟件維護工作。通常,系統(tǒng)架構(gòu)師將復(fù)雜的系統(tǒng)功能分為較小的組件,以便由不同的開發(fā)小組實現(xiàn)。因此,描述不同組件之間連接的接口定義,不僅詳細(xì)說明了可以在組件間傳遞的參數(shù)類型,還包括在每個組件中必須實現(xiàn)的實時處理的限制,能減少軟件維護方面的開銷。

對于現(xiàn)有軟件的修改必須遵從組件接口注釋中描述的所有其它特殊實時限制。如果軟件維護人員違反了這些接口要求,他們可以從字節(jié)碼驗證器得到直接、明確的反饋。從而確保現(xiàn)有大型實時軟件系統(tǒng)的不斷變化不會動搖現(xiàn)有系統(tǒng)的穩(wěn)定性。

在對可靠運行該主程序所需的堆棧內(nèi)存進行分析時,靜態(tài)分析器必須確定在該方法以及該方法所調(diào)用的方法中,每個對象要求分配多大內(nèi)存。為了支持靜態(tài)分析結(jié)果的模塊化合成,字節(jié)碼驗證器要求每個由主程序調(diào)用的方法被聲明為@Static-Analyzable,而enforce_time_ analysis屬性設(shè)置為true??焖購?fù)查main方法的實現(xiàn)可確保無限循環(huán)內(nèi)不產(chǎn)生分配。這是字節(jié)碼驗證器所要執(zhí)行的任務(wù)之一。

在第37行的socket_reader_thread = new Thread-Stack(SocketReader.class);到41行的orchestrator_thread = new ThreadStack(Orchestrator.class)之間分配了幾個新的ThreadStack對象;每次分配描述了主程序派生的線程所使用的堆棧內(nèi)存。一般來說,靜態(tài)分析工具可能難以確定可靠執(zhí)行這些子線程所必需的堆棧內(nèi)存數(shù)量。

每個ThreadStack構(gòu)造函數(shù)的參數(shù)為提供代碼由相應(yīng)線程執(zhí)行的類(Class)。靜態(tài)分析器要求每個在該環(huán)境中傳遞的NoHeapRealtimeThread子類具有帶@ StaticAnalyzable注釋,且enforce_ memory_analysis屬性設(shè)置為true的run()方法。如果ThreadStack構(gòu)造函數(shù)的參數(shù)并非來自BoundAsyncEventHandler(例如在Orchestrator類的情況下),則靜態(tài)分析器要求該類的asyncEventHandler()方法采用@StaticAnalyzable注釋來聲明,且enforce_memory_analysis屬性設(shè)置為true。

當(dāng)前線程的運行時棧能滿足所有臨時內(nèi)存需要。請注意,我們在第23行分配了兩個臨時BufferPair實例,microphone_stream = new BufferPair();而在第24行,speaker_stream = new Buffer-Pair();然后這些對象的參數(shù)被傳遞至構(gòu)造函數(shù),用于包含該軟件應(yīng)用的不同功能組件的各個線程。硬實時驗證器實施的限制之一在于,stack-allocated對象的參數(shù)不能比引用參數(shù)的對象本身生存時間更長,同樣是通過注釋機制來執(zhí)行。我們來看一下SocketReader類的構(gòu)造函數(shù):

@ScopedPure
@StaticAnalyzable(enforce_time_analysis = {false}, enforce_non_blocking = {false})
SocketReader(SimpleAudio sa, Buffer-Pair buffers, String socket_name) throws
FileNotFoundException

@ScopedPure注釋說明該構(gòu)造函數(shù)的每個輸入引用參數(shù)(reference parameter)可以指代那些位于外部嵌套作用域的運行時棧的對象。字節(jié)碼驗證器確保這些參數(shù)的內(nèi)容絕不會復(fù)制到那些由于具有@Scoped指派而未被同樣區(qū)分的變量上。

此外,它禁止將內(nèi)部嵌套作用域變量的值復(fù)制到外部嵌套作用域變量。一個例外情況是,在特殊環(huán)境下,它可證明帶參數(shù)對象位于與要賦值變量相同或更外層嵌套的作用域。如果這一構(gòu)造函數(shù)的參數(shù)未由@Scoped注釋指定,字節(jié)碼驗證器將不允許主程序?qū)?shù)傳至堆棧分配的BufferPair和SimpleAudio對象。

本應(yīng)用展示的RTSJ支持的實時編程抽象之一為PeriodicTimer類。注意,本應(yīng)用在第49行舉例說明了PeriodicTimer對象,drumbeat = new PeriodicTimer(start_time, period, orchestrator);并將結(jié)果賦值給本地drumbeat變量。參數(shù)之一為orchestrator對象的引用參數(shù),其本身是BoundAsyncEventHandler的一個實例。該drumbeat周期計時器被設(shè)置為每秒觸發(fā)orchestrator對象的handleAsyncEvent()方法執(zhí)行16次,即每62.5微秒一次。

采用C或C++語言的實時開發(fā)人員可以實現(xiàn)這些實時Java技術(shù)所支持的許多相同構(gòu)造。但是,C或C++程序員必須產(chǎn)生懸掛指針(dangling pointer)以及內(nèi)存泄漏,他們還缺乏標(biāo)準(zhǔn)工具的支持來自動分析執(zhí)行時間和堆棧大小。

另外,C和C++程序員還缺乏完整性檢查以確保方法的實現(xiàn)能夠滿足文檔化實時接口的要求,并確保方法調(diào)用能夠傳遞同樣滿足文檔接口要求的參數(shù)。最后,在對現(xiàn)在軟件系統(tǒng)進行維護的過程中,C和C++程序員沒有工具支持來保證對現(xiàn)有軟件的修改與在原軟件開發(fā)過程中假設(shè)的各種組成要求是相符的。

傳統(tǒng)Java在生產(chǎn)效率和成本上具有許多優(yōu)勢。規(guī)范地使用實時Java技術(shù)可提供許多這樣的優(yōu)勢。與使用C和C++相比,一般Java程序員在新代碼開發(fā)期間具有2倍的生產(chǎn)率,而在現(xiàn)在軟件維護期間具有5到10倍的生產(chǎn)率。隨著嵌入實時軟件的大小和復(fù)雜度增加,這些激發(fā)人們向更現(xiàn)代的軟件工程技術(shù)(如由實時Java實現(xiàn)的工程技術(shù))轉(zhuǎn)化的因素已越來越重要了。



評論


相關(guān)推薦

技術(shù)專區(qū)

關(guān)閉