利用實時Java設計數字音頻系統(tǒng)
如今，在低級、硬件、實時軟件領域已有各種各樣的Java方案。但是，當在像數字音頻信號處理這樣非常低級的軟件中應用Java技術時，某些方案將更能發(fā)揮傳統(tǒng)Java技術的優(yōu)越性。
其中一種方法基于針對資源受限和安全關鍵的Java定義的推薦規(guī)范。設計該方案的主要目的是保持Java的可移植性、可維護性和可擴展性優(yōu)勢。在系統(tǒng)內的信息流中包括兩臺計算機，這兩臺計算機協同操作以便通過網絡通訊通道交換音頻信息(圖1)。
在一個節(jié)點上采集到的音頻信號被傳輸至其它節(jié)點，并被輸出至遠程計算機的揚聲器。在第二個節(jié)點上采集到的音頻信號則在第一臺計算機的揚聲器中輸出。從概念上講，信息流被構造成兩個獨立的數字音頻數據流。
這種簡單的音頻處理應用可以被當作PERC Pico應用程序來實現。該軟件目前正在開發(fā)中，它首次實現了針對安全關鍵和資源受限應用所提出的實時Java(RTSJ)規(guī)范概要分析。“硬實時概要分析(hard real-time profile)”即指這種環(huán)境。
 |
| 圖1：一個簡單的數字音頻應用構成了本文討論的關鍵性軟件工程的基礎。 |
維護和可擴展性要求
摩爾定律推動了典型嵌入式應用的規(guī)模和復雜度快速增長。競爭壓力促使軟件不斷發(fā)展，以滿足功能越來越強大的硬件的需求。對某些消費電子設備的研究發(fā)現，新產品中代碼規(guī)模的增長速度非常接近摩爾定律，大約每18至36個月就翻一番。
大約20年前，每個新的嵌入式設備中的所有軟件通常是由一個或兩個工程師在不到一年的時間內寫完。而現代嵌入式軟件的開發(fā)則非常困難。假設每次新產品的軟件修訂都要求增加數十萬，甚至數百萬行的代碼，那么嵌入式軟件開發(fā)人員的職責將更多地轉向如何解決集成許多獨立開發(fā)的軟件組件所帶來的挑戰(zhàn)。
這個簡單的數字音頻例子代表了一種原型的低級嵌入式軟件“產品”。對大多數產品而言，開發(fā)原始軟件的成本要比整個產品生命周期內的軟件維護成本小得多。以下列出了該應用在產品生命周期內的發(fā)展過程。
(1)軟件將需要被移植到不同的操作系統(tǒng)和不同的處理平臺上，這將改變它的CPU時間和內存需求。
(2)軟件將與各種不同的補充功能集成在一起。也許下一代產品也將包括視頻信號。也許它將支持共享數字白板，以便于召開遠程會議，或者可能與電子郵件和日歷軟件集成在一起。或者，一些應用可能增加錄制功能，以將會議實況保存在磁盤中。
(3)雙節(jié)點網絡拓撲可能需要進行通用化，以支持有任意多參加者的會議。
(4)模數轉換器(ADC)和數字信號處理器(DSP)的接口可以不斷發(fā)展。在一些配置中，操作系統(tǒng)提供了這種服務。而在其它配置中，這種應用可能包括連接音頻子系統(tǒng)硬件和DMA內存設備的設備驅動程序接口。音頻硬件本身有望繼續(xù)發(fā)展，這要求軟件設備驅動程序不斷發(fā)展。
(5)網絡通信協議可能需要作一些改變。在某些環(huán)境中，軟件將依賴底層操作系統(tǒng)服務來與網絡連接。隨著各種網絡通信協議的發(fā)展，連接操作系統(tǒng)網絡業(yè)務的接口甚至也可能發(fā)生變化，以便提供新的QoS參數和更高帶寬。在其它情況下，這種應用將需要包含面向硬件接口的低級設備驅動程序，也可能需要實現通信協議棧?？梢圆捎脦_突檢測的載波偵聽多路訪問(CSMA/CD)技術、無線、光纖和其它有待發(fā)明的技術，在低成本專用串行通道、同軸電纜和雙絞線數據鏈接中實現相同的基礎通信能力。通信庫可能集成了壓縮、加密、檢錯和糾錯，以及滑動窗口協議。
上面給出了軟件在商業(yè)化業(yè)務應用中的幾種可能發(fā)展方式，這里并非想窮舉所有的優(yōu)勢，只是為了說明保留Java設計優(yōu)勢的好處，即使是對于一些資源受限和硬實時應用來說。
 |
| 圖2：硬實時JAVA翻譯環(huán)境顯示了各種工具之間的關系，這些工具可使實時組件的開發(fā)、維護和集成更容易。 |
實時JAVA的能力
這些實時Java編程技術由RTSJ衍生發(fā)展而來。該規(guī)范具有很好通用性，能支持多種獨特的實時編程要求。由于本文主要關注非常低級的實時軟件，所以我們將開發(fā)人員的操作限定在完整RTSJ規(guī)范的子集范疇內。
這種概要分析可改善可移植性、可靠性和效率，因為它禁止使用一些需要很大的運行時間開銷、會帶來不可移植的實現依賴性、增加軟件復雜度以致使程序員更容易出錯的功能。硬實時概要分析和完整RTSJ之間一些特殊差異包括：
(1)完整的RTSJ對同步鎖采用優(yōu)先級繼承方法，并支持優(yōu)先級限高仿真可選。硬實時概要分析禁止使用優(yōu)先級繼承并要求支持優(yōu)先級限高仿真。
(2)完整的RTSJ允許即時修改各種線程調度和對象同步參數。硬實時概要分析禁止對線程調度和同步協議進行即時調整。
(3)完整的RTSJ還支持一些機制，這樣每當任務錯過最終期限或超出其CPU時限時，就可以自動觸發(fā)異步事件。請注意，這些服務的實現是完全不可移植的，而精確執(zhí)行會帶來極高的運行時間開銷。此外，在硬實時應用中不需要運行時間限制，因為在程序執(zhí)行之前，已經靜態(tài)地滿足資源預算和最終期限要求。因此，硬實時概要分析不支持這些機制。
(4)完整的RTSJ支持傳統(tǒng)線程、訪問垃圾收集堆的實時線程，以及不訪問垃圾收集堆的實時線程的混合體。這種不同線程類型的混合大大增加了系統(tǒng)的復雜度和規(guī)模。這種復雜度將增加由于不同線程類型之間不能正確共享信息而導致的實時編程出錯的可能性，硬實時概要分析僅支持不訪問垃圾收集堆的實時線程。
(5)完整的RTSJ提供一系列可供應用程序員使用的庫，以便舉例說明動態(tài)內存范圍，并在特定范圍內分配對象。由于程序員在開發(fā)或集成采用嵌套作用域(nested scope)的組件時可能會產生許多小錯誤，所以這些庫的使用尤其成問題。為執(zhí)行正確的區(qū)域性存儲器(scoped-memory)使用協議，RTSJ在每次讀取和/或重寫參考字段時都執(zhí)行特殊的運行時檢查。在完整的RTSJ中，運行時進行檢查會使程序組件出錯，從而使得程序由于非法分配、非法讀取、區(qū)域性存儲器協議錯誤、內存不足錯誤等原因，以運行時間異常方式終止執(zhí)行。硬實時概要分析禁止使用RTSJ內存作用域(memory scope)操作庫。相反，它要求程序員以編程注釋的形式描述其對作用域內存(scoped-memory)的使用。在編譯期間，這些注釋可以被分析和執(zhí)行，例如本文應用提到的@Scoped和@StaticAnalyzable注釋。
(6)RTSJ不會為了中斷處理或低級設備的I/O而對庫進行標準化，而硬實時概要分析對這些庫進行定義。
硬實時概要分析的商用化前實現試驗顯示，它運行在某些CPU密集型基準程序的速度比標準Java和完整RTSJ的速度快三倍。這是因為硬實時執(zhí)行環(huán)境比標準RTSJ簡單得多，并且它還用編譯時間驗證替代各種運行時檢查。這種性能可以與相應的C和C++程序相媲美，有時甚至更好。
盡管采用受限的硬實時概要分析比采用傳統(tǒng)Java更加困難，但這種平臺的代碼開發(fā)和維護要比用C或C++開發(fā)出的相應平臺的維護容易。這是因為硬實時Java平臺具有更好的可移植性，并提供高級的面向對象的抽象。此外，硬實時Java平臺包括可使實時組件的開發(fā)、維護和集成更為容易的一些重要開發(fā)工具(圖2)。
由于包含了強制嚴格遵守類型安全的字節(jié)碼校驗器，與C和C++相比，Java開發(fā)可提高可靠性和可維護性。C和C++程序員可以利用多種讓使類型安全無效的機制，而有意或無意地利用這些漏洞將使代碼更容易產生錯誤，并降低可移植性。
受限的實時環(huán)境提供了比傳統(tǒng)Java更嚴格的字節(jié)碼驗證。特別是，圖2中的硬實時驗證器可確保指向堆棧分配對象的參數(指針)不會比對象本身的生存期更長。它也確保用專用@StaticAnalyzable注釋標記的程序組件，可限制它們對可分析子集使用Java。與硬實時翻譯器的集成，則能提供確定執(zhí)行每個組件所需的CPU時間和堆棧內存上限的能力。
執(zhí)行硬實時組件所需的所有臨時內存分配，必須由正在執(zhí)行線程的運行時棧來實現。執(zhí)行從單主線程開始，而主線程的運行時棧代表了所有可重復使用的內存。對于由主線程派生的每個附加線程，它提供了部分運行時棧作為派生線程的運行時棧。
 |
| 圖3：該模塊圖說明了SimpleAudio數字音頻應用的體系結構。 |
數據音頻應用的實現
圖3給出了數字音頻應用的體系結構。它共有6個線程，包括主線程和用Orchestrator實例表示的異步事件處理器。BufferPair將每個插座接口連接至相應的DSP接口。主線程監(jiān)控用戶指令，并在用戶請求關閉會話時調用SimpleAudio實例的terminateActivity()方法。所有其它線程通過調用continueActivity()業(yè)務，定期輪詢SimpleAudio實例。到了關機時，該方法返回false值。
在缺省配置中，該應用以8kHz采樣頻率對麥克風輸入進行采樣，每次采樣采集8比特數據。這種配置每秒鐘產生8k字節(jié)的數字音頻數據，這對簡單的語音應用來說已經足夠。但是，它不適合高保真立體聲信號。一般的CD錄制以44.1kHz的采樣頻率對兩個立體聲信道每次采樣16比特。這種高保真度信號的帶寬要求為176.4千字節(jié)/秒。
在缺省配置中，插槽讀模塊和寫模塊采用足夠的帶寬進行可靠傳輸，以可靠提供所有從DSPReader模塊采集的數據。我們采用了一種直接壓縮技術，一連串同樣的字節(jié)值(像出現在靜音期間的那樣)由一個專用的轉義(escape)值、重復次數和重復值表示。當然，更先進的壓縮技術將更為合適。
在實時系統(tǒng)中，由抖動描述特定實時組件的理想執(zhí)行時間的預期偏離，由一個確切的線程描述數字音頻應用的每個組件。SocketWriter線程接收來自DSPReader模塊的原始數據流，對數據進行壓縮，并將數據傳送至網絡插座通道。如果網絡插座通道的帶寬有限，只能達到預算的8千字節(jié)/秒，那么任何導致SocketWriter延遲數據傳輸的抖動影響將隨著時間而累積。
在缺省配置中，預計SocketWriter每125µs傳輸1字節(jié)數據。如果每秒的音頻數據有1個字節(jié)延遲半毫秒，則1小時后，累積延遲將約為2秒。為防止抖動延遲的累積，該架構包含一個運行在16Hz的監(jiān)視線程。
在每個周期內，該線程強制讓SocketWriter和DSPWriter組件丟棄62.5ms之前的數據。由于我們處理的是音頻數據，所以通常來講，丟棄的臨時數據值比允許數據到達時間偏移更可取一些。人們通常不會注意到丟棄臨時數據字節(jié)的影響。
請注意在第1行出現的@StaticAnalyzable注釋，源碼列表中的@ StaticAnalyzable(enforce_time_analysis = {false}, enforce_non_blocking = {false})。這代表了部分方法簽名(method signature)。注意該注釋給出了enforce_time_analysis 和enforce_non_blocking屬性的參數值，兩者都是false。這表示該方法的實現無需將其本身限制在子集內，對于該子集，靜態(tài)分析器可從中推斷執(zhí)行該方法所需要的嚴格CPU時間上限，也不要求靜態(tài)分析器驗證該方法執(zhí)行時永遠不會阻斷。
如果這些屬性定義沒有給出，硬實時驗證器將認為程序不合法，因為在源碼列表的(!orchestrator.destroy()) { through 57, }執(zhí)行時，靜態(tài)分析器無法確定該循環(huán)包含了多少次第55行。此外，main方法的執(zhí)行可能會在第59行的socket_ reader_thread.join()至63行的orchestrator_thread.join()之間阻斷，以及在第51行sa.awaitTermination()調用的await-Termination()方法中阻斷。
在@StaticAnalyzable注釋中未注明的是enforce_memory_analysis屬性的值。該屬性的缺省值為true，這意味著該方法的實現必須符合限定的指導方針以使執(zhí)行該方法時靜態(tài)分析器能夠確定將要分配的最大內存。假設該環(huán)境的實時Java規(guī)則將內存作為運行棧的一部分，則臨時內存分配的上限就表示必需的主線程的運行時棧大小。
注釋有助于軟件開發(fā)，并大大簡化軟件維護工作。通常，系統(tǒng)架構師將復雜的系統(tǒng)功能分為較小的組件，以便由不同的開發(fā)小組實現。因此，描述不同組件之間連接的接口定義，不僅詳細說明了可以在組件間傳遞的參數類型，還包括在每個組件中必須實現的實時處理的限制，能減少軟件維護方面的開銷。
對于現有軟件的修改必須遵從組件接口注釋中描述的所有其它特殊實時限制。如果軟件維護人員違反了這些接口要求，他們可以從字節(jié)碼驗證器得到直接、明確的反饋。從而確?，F有大型實時軟件系統(tǒng)的不斷變化不會動搖現有系統(tǒng)的穩(wěn)定性。
在對可靠運行該主程序所需的堆棧內存進行分析時，靜態(tài)分析器必須確定在該方法以及該方法所調用的方法中，每個對象要求分配多大內存。為了支持靜態(tài)分析結果的模塊化合成，字節(jié)碼驗證器要求每個由主程序調用的方法被聲明為@Static-Analyzable，而enforce_time_ analysis屬性設置為true。快速復查main方法的實現可確保無限循環(huán)內不產生分配。這是字節(jié)碼驗證器所要執(zhí)行的任務之一。
在第37行的socket_reader_thread = new Thread-Stack(SocketReader.class)；到41行的orchestrator_thread = new ThreadStack(Orchestrator.class)之間分配了幾個新的ThreadStack對象；每次分配描述了主程序派生的線程所使用的堆棧內存。一般來說，靜態(tài)分析工具可能難以確定可靠執(zhí)行這些子線程所必需的堆棧內存數量。
每個ThreadStack構造函數的參數為提供代碼由相應線程執(zhí)行的類(Class)。靜態(tài)分析器要求每個在該環(huán)境中傳遞的NoHeapRealtimeThread子類具有帶@ StaticAnalyzable注釋，且enforce_ memory_analysis屬性設置為true的run()方法。如果ThreadStack構造函數的參數并非來自BoundAsyncEventHandler(例如在Orchestrator類的情況下)，則靜態(tài)分析器要求該類的asyncEventHandler()方法采用@StaticAnalyzable注釋來聲明，且enforce_memory_analysis屬性設置為true。
當前線程的運行時棧能滿足所有臨時內存需要。請注意，我們在第23行分配了兩個臨時BufferPair實例，microphone_stream = new BufferPair()；而在第24行，speaker_stream = new Buffer-Pair()；然后這些對象的參數被傳遞至構造函數，用于包含該軟件應用的不同功能組件的各個線程。硬實時驗證器實施的限制之一在于，stack-allocated對象的參數不能比引用參數的對象本身生存時間更長，同樣是通過注釋機制來執(zhí)行。我們來看一下SocketReader類的構造函數：
@ScopedPure
@StaticAnalyzable(enforce_time_analysis = {false}, enforce_non_blocking = {false})
SocketReader(SimpleAudio sa, Buffer-Pair buffers, String socket_name) throws
FileNotFoundException
@ScopedPure注釋說明該構造函數的每個輸入引用參數(reference parameter)可以指代那些位于外部嵌套作用域的運行時棧的對象。字節(jié)碼驗證器確保這些參數的內容絕不會復制到那些由于具有@Scoped指派而未被同樣區(qū)分的變量上。
此外，它禁止將內部嵌套作用域變量的值復制到外部嵌套作用域變量。一個例外情況是，在特殊環(huán)境下，它可證明帶參數對象位于與要賦值變量相同或更外層嵌套的作用域。如果這一構造函數的參數未由@Scoped注釋指定，字節(jié)碼驗證器將不允許主程序將參數傳至堆棧分配的BufferPair和SimpleAudio對象。
本應用展示的RTSJ支持的實時編程抽象之一為PeriodicTimer類。注意，本應用在第49行舉例說明了PeriodicTimer對象，drumbeat = new PeriodicTimer(start_time, period, orchestrator)；并將結果賦值給本地drumbeat變量。參數之一為orchestrator對象的引用參數，其本身是BoundAsyncEventHandler的一個實例。該drumbeat周期計時器被設置為每秒觸發(fā)orchestrator對象的handleAsyncEvent()方法執(zhí)行16次，即每62.5微秒一次。
采用C或C++語言的實時開發(fā)人員可以實現這些實時Java技術所支持的許多相同構造。但是，C或C++程序員必須產生懸掛指針(dangling pointer)以及內存泄漏，他們還缺乏標準工具的支持來自動分析執(zhí)行時間和堆棧大小。
另外，C和C++程序員還缺乏完整性檢查以確保方法的實現能夠滿足文檔化實時接口的要求，并確保方法調用能夠傳遞同樣滿足文檔接口要求的參數。最后，在對現在軟件系統(tǒng)進行維護的過程中，C和C++程序員沒有工具支持來保證對現有軟件的修改與在原軟件開發(fā)過程中假設的各種組成要求是相符的。
傳統(tǒng)Java在生產效率和成本上具有許多優(yōu)勢。規(guī)范地使用實時Java技術可提供許多這樣的優(yōu)勢。與使用C和C++相比，一般Java程序員在新代碼開發(fā)期間具有2倍的生產率，而在現在軟件維護期間具有5到10倍的生產率。隨著嵌入實時軟件的大小和復雜度增加，這些激發(fā)人們向更現代的軟件工程技術(如由實時Java實現的工程技術)轉化的因素已越來越重要了。
下載文檔
