Porting AAC Decoder - 皓鈞

2009.09.18 - Progress update

‧改完第20個動態宣告，這一部分到目前先告一個段落。

[繼續閱讀]

‧接下來要把程式放到VisualDSP++上面去跑，預計還會遇到一些記憶體空間不足的問題。

2009.09.11 - Progress update

‧改完第19個動態宣告。

2009.09.04 - Progress update

‧改完第18個動態宣告。

2009.09.01 - Progress update

‧改完第16、17個動態宣告。

 

 

 

//////////////////////////////////////////////////////////
↓↓↓↓↓↓↓↓↓↓                           歷史紀錄                           ↓↓↓↓↓↓↓↓↓↓
//////////////////////////////////////////////////////////

2009.02.24 - AAC decoder porting progress

1. 這次的工作是把AAC Decoder porting到2191上面，這原本應該是很久以前的工作。
2. AAC的版本是HimaxDecoder20080408_V870(Final)，然後不包含SBR和PS的部分。
3. 目前先移除原本程式中Fixed Point的部分以及測量用的時間標籤，然後先把程式中動態宣告的資料改成靜態宣告的方式，不過這部分還沒有全部改完。
4. 有一些之前已經知道會遇到的問題之後得再去想辦法解決包括：
     a.記憶體大小、配置的問題。
     b.CCE的問題。

[ 投影片 ]

 

--------------------------------------------------------------------------------

2009.02.27 - Some previous AAC related things

01 - Tree  of  function  call  

這是 Himax Decoder V870 的 Function Call 的樹狀結構，內容為各個function之間的呼叫關係。使用投影片放映模式，區塊代表function。其中：藍色區塊代表該function下層沒有呼叫其他function，而紅色區塊代表該function下層還有呼叫其他function。藍色向右的箭號會跳到下一層function所在的投影片，而橘色向左的箭號則會跳回上層function所在的投影片。至於左下角的房子則會跳到最上層的投影片。

[ 投影片 ]

 

02 - AAC function analysis 1  

這是當時想知道哪些function比較耗計算時間所做的第一次測試，不過當時不曉得，所以把寫檔的時間(OutputToPcm)也算了進去。

[ 投影片 ]

 

03 - AAC function analysis 2  

這是後來做的第二次測試結果，選了一首兩分半流行樂以及AAC的一些Testing Bitstream當作測試音檔。主要針對RawDataBlockCheckCCE、RawDataBlock、IndividualChannelStream還有一些其他的function(例如：ms、is)去測試。測試結果中的Time代表的是每個function跑的時間，單位是ms；Ratio1代表的是該function在上層呼叫的function中所佔的比率；Ratio2代表的則是該function在全部時間中所佔的比率。

[ 投影片1 - Testing bitstream and partial results ]
[ 投影片2 - Total testing results ]

 

04 - AAC decoder v870 about CCE  

這部分簡介了一下CCE(Coupling Channel Element)，CCE主要是用於多聲道時，可將多個聲道中共同的部分擷取出來一起編碼，然後於解碼還原時再分別疊加回原本的各個聲道中。程式中須透過RawDataBlackcheckCCE這個function來得知哪些地方使用了CCE，並且將其資訊儲存於hDecoder這個指標指向的struct中，當還原時若需要CCE資訊，再到該struct中讀取。

[ 投影片 ]

 

05 - Known problems on 2191  

這部分放上2191的記憶體分配，以及在2191上已經知道會遇到的一些問題，包括：a.不能使用malloc動態配置記憶體空間，須使用靜態宣告。b.在AAC Decoder V870中的struct Decoder_Struct光宣告就占掉了45K的大小，但是2191上的記憶體空間(DM1+DM2)大概只有27K多。c.若要使用外部記憶體，須透過external _memory_read和external _memory_write這兩個function。

[ 投影片 ]

--------------------------------------------------------------------------------

2009.03.11 - Progress update

之前原本打算先把程式中動態宣告的部分改成靜態宣告，程式中一共有21的地方有使用到動態宣告，目前只改完其中2個。因為在改第3個的時候，有其他2個動態宣告和它有相關，所以當時一起改，不過改完之後，compile雖然有過，可是執行時就是會有問題。

 

2009.04.02 – Progress update

• 把之前執行時會有問題的版本先回復到前一版，修改完第3個使用動態宣告的地方。

2009.04.08 – Progress update

• 改完第4個動態宣告。

2009.04.13 – Progress update

• 總共有二十個地方要改，目前改完第五個。
• 修改的原因是因為VisualDSP++不支援動態宣告的方式，所以必須改為靜態宣告。

2009.04.16 – Progress update

• 改完第6個動態宣告。

2009.07.03 – Progress update

• 這部分停了一陣子沒動，之前改的也有點忘記  @@，現在繼續改之前沒改完的部分，希望能盡快改完。
• 目前改完第7個動態宣告。

2009.07.10 - Progress update

• 改完第8個動態宣告。

2009.07.17 - Progress update

• 改完第9個動態宣告。

2009.07.24 - Progress update

• 改完第10個動態宣告。

2009.07.31 - Progress update

• 改完第11個動態宣告。

2009.08.07 - Progress update

• 改完第12個動態宣告。

2009.08.14 - Progress update

• 改完第13個動態宣告。
• 目前這部分要修改的地方一共有20個。
• 修改後的結果和原本的比較應該是一樣的，並沒有比較好。

2009.08.21 - Progress update

• 改完第14個動態宣告。 

2009.08.28 - Progress update

• 改完第15個動態宣告。

2009.09.01 - Progress update

• 改完第16、17個動態宣告。

2009.09.04 - Progress update

• 改完第18個動態宣告。

2009.09.11 - Progress update

• 改完第19個動態宣告。

--------------------------------------------------------------------------------

Cyber Simulation - 宗胤

--- [09.09.16] ------------------------------------------------

目前完成的部份是可以將一個簡單的加減法電路掛到CDK板子的FPGA上，並且可透過ICE Server讓Host (PC)存取這個加減法電路，也可讓CDK上的Linux透過Driver使一隻User Space的程式可以存取這個電路。

CDK上的FPGA是透過AHB或APB與其他的硬體作溝通，因此要在FPGA上實作電路必須要實做與AHB或APB溝通的interface，這個interface我是直接使用CDK所給的範例裡的，我只修改最底層的電路。

另外，照CDK的規格書所述，基本上我們可以在fpga上實作兩個Slave掛在AHB下，而Bus上的Memory Map是已經給定好的：

1. Slave1是Map在0x1CB20000，大小為2MB
2. Slave2是Map在0x1CD20000，大小為2MB

因此我透過範例的interface將電路實作在Slave1裡，讓其他硬體可透過0x1CB20000這個位址與其作溝通。

上面是利用ICE Server讓Host在CDK上跑一隻簡單的程式，其中紅框中的slavebase即是儲存0x1CB20000，然後就透過存取slavebase直接與FPGA的電路溝通。藍框中是執行的結果。

而上圖則是先在CDK上boot Linux後，利用我寫的簡單driver (calculate.ko)來讓armtest這隻程式可以輸入2個數值給電路來做相加和相減。基本上armteset是透過ioctl這個function來與硬體做溝通，程式碼如下，將Device打開就利用driver事先定義好的command發命令至driver，driver再根據command控制加減法電路。

再來應該是要做關於driver codegen的部份，但要寫codegen的話勢必要有一定程度至瞭解Linux driver，所以我想我應該要找個driver trace。

有關Group Meeting

2009, 9/15

DNA : 新的時間表 嘎喔

時間: 星期四下午2:00

地點: 未定 (暫定4282)

報告順序:

日期	報告成員
9/24	阿凡、小聽
10/1	皓鈞(補)、宗胤(補)
10/8	仕偉、品皓、大鈞
10/15	胤霖、宗胤、小明
10/22	嚕嚕、塞公、偉翔
10/29	小龍、雙魚、皓鈞
11/5	阿凡、小聽
11/12	仕偉、品皓、大鈞
11/19	胤霖、宗胤、小明
11/26	嚕嚕、塞公、偉翔
12/3	小龍、雙魚、皓鈞
12/10	阿凡、小聽
12/24	仕偉、品皓、大鈞
12/31	胤霖、宗胤、小明
1/7	嚕嚕、塞公、偉翔
1/14	小龍、雙魚、皓鈞
1/21	阿凡、小聽
1/28	仕偉、品皓、大鈞
2/4	胤霖、宗胤、小明
2/11	嚕嚕、塞公、偉翔

------------------------------------------------------------------

2009, 9/15

新的Group Meeting時間為每星期四下午兩點.

請DNA重新排報告的同學的時間表

------------------------------------------------------------------

2009,9/9

開學後的Group meeting請重新調查時間. 我的上課時間是:

(三)6~8. RM4261. 研究所的Multicore的課.

(四)2~4. RM4263. 大學部的System Level Programming

請大家上來說一下自己的上課時段, 請DNA排出時間並借教室.

至於Meeting的內容還是以報Paper為主, 每次三位同學比較好, 否則兩個月才會輪一次, 有點久.

Meeting的另一個目的本來是報告進度, 不過我覺得大家也許感到還沒做到一個地步就報告會不知道報什麼. 所以就改成你做到可以初步展示時再上來就好. 但是我又不希望隔太久, 所以強制一下, 一個月來展示一次. 但是我請大家自動自發, 每個禮拜在你的工作串上發表進度. 發表內容希望言之有物, 讓人知道你在做什麼. 也就是要交代前因與結果.

並且, "把串提到上面來, 並註明更新日期"

明年想畢業的同學, 固定兩星期上來展示一下你的成果. 所謂展示, 不是口頭報告, 要有Demo才行.

另外, 等穩定後, 約在十月中, 如我所說我會再找時間, 由我或博士班的學長幫碩一同學上一些課. 並且定一下個別meeting的時間與方式.

-----------------------------------------------------------------

4285被張大偉老師借去，奇怪的是他們每週二都註明是training course，晚點去系辦反應完看看能不能換，我們人數較多要借較大的教室。

時間: 早上10點

地點: 未定

報告順序:

日期	報告成員
8/11	品皓、仕偉
8/18	胤霖、大鈞
8/25	小明、宗胤
9/1	塞公、嚕嚕
9/8	偉祥、皓鈞
9/15	小龍、雙魚
9/22	阿凡、小聽
9/29
10/6	品皓、仕偉
10/13	胤霖、大鈞
10/20	小明、宗胤
10/27	塞公、嚕嚕
11/3	偉祥、皓鈞
11/10	小龍、雙魚
11/17	阿凡、小聽
11/24

進度報告: 每兩週一次

其他注意事項:

1. 論文不知道要報什麼的請找你的Mentor或找老師。
2. 下週三(8/12)早上10點大掃除！

演講：探索嵌入式 ARM 平台與 SoC -- Part I + Part II

演講：探索嵌入式 ARM 平台與 SoC -- Part I + Part I

推薦一下這個演講，講師是鼎港有名聲，下港尚出名ㄟ黃敬群(Jserv)
有在做ESL/ARM相關的人或有興趣的人可以去聽一下
看真實的系統長什麼樣，以軟體的角度是怎樣看待ARM/SoC System
業界又是如何來設計及使用ARM/SoC System
我相信Jserv可以提供許多寶貴的意見
詳細的時間地點，請參照連結內容

閒閒沒事做的，也可以去看一下本系有史以來最強的學長本尊
在現場你一定可以感受到他的無邊法力 XD

Vertical Bit Map Coding

[2009-09-20]

Bad news. I have found one bug in my Matlab code. The bitrate counter have been implemented in a wrong way so that the bitrate have been overcounted. The bitstream of 32kbps is actually the bitstream of 64kbps. Therefore, the coding efficiency shall be further underestimated.

=====================================================

A. Introduction
For recording my research in audio bit plane coding technique, here I demonstrate a series of decoded results produced by a fine-grain-scalable lossy-to-lossless audio coder. The key idea is quite simple but effective. From my doctoral study, I learned the significant map (the most significant bits of all coefficient to be encoded) plays a critical role in both coding efficiency and audio quality. If I can use as less bits as possible to encode the significant map, then the decoded quality will be as good as possible even in a very low bitrate. Unlike the scalable audio coder, Harmonic Quad Tree coding (HQT), in my doctoral thesis, this coder explores the relationship between the most significant bits of two adjacent frequency coefficients, not harmonic relationships among frequency coefficients. In addition, the bit plane coding technique, Set Partitioning In Hierarchical Trees (SPIHT), is absent in the new coder. I would like to named this coder as Vertical Bit Map coding (VBM) at this moment.

B. Experiment
The chosen test audio piece is from "castant" which is a famous test material for audio compression. Due to its rich and fast claps, the audio artifact so called "pre-echo" can be easily perceived after lossy compressed.

The following two examples show an interesting function I called it variable bitrate playback. To make you quickly understand this function, I decoded the bitstreams according a series of specified varying bitrates frame by frame and drawn their spectrum. The figures have the original spectrum in the top, the decoded spectrum in the middle, and the specified varying decoding bitrate of each frame in the bottom.

The first experiment is set the varying bitrate from 16kbps to 64kbps in a step size of 2kbits.

The second experiment is set the varying bitrate from 32kbps to 64kbps in a step unit of 1kbits.
The audio qualities are very defective because these two experiments are extraordinary only for demonstration. In an usual scenario, the varying decoding bitrate is expected to change in a smooth way. For keeping acceptable audio quality, the decoding bitrate would not be allowed to adjust so frequently and amplify so large range in a short time.

There are also some comparsions with other scalable audio coders. They can be downloaded from Result Comparsion, all 44.1KHz, 16-bit, mono.

The file list describes briefly here,
cast_ori.wav – castant original wave file
cast_rec_(16_64_2kbps).wav – the first experiment
cast_rec_(32_64_1kbps).wav – the second experiment
cast_rec_(16kbps).wav – 16kbps fixed rate VBM version
cast_rec_(32kbps).wav – 32kbps fixed rate VBM version
cast_rec_(64kbps).wav – 64kbps fixed rate VBM version
cast32_bsac.wav – 32kbps fixed rate MPEG4 BSAC version
cast32_sac.wav – 32kbps fixed rate Scala SAC version
cast32_hqt.wav – 32kbps fixed rate HQT version
cast32_eac.wav – 32kbps fixed rate Mircosoft EAC version

C. Summary
As a conclusion and a reminder for myself, this VBM coder is an experiment of my speculation in the importance of significat map in audio coding. This VBM audio coder can be categorized as:
1. Fine-scalability: scalable grain is downto 1 bit,
2. Lossy-to-lossless: the embedded bitstream contains all possible playback bitrates, even the archive,
3. Low complexity: there are very few prediction calculations and history storages in analyzing and reconstucting the significant map. Therefore it can be claimed that complexity is equivalent and low in both encoding and decoding,

and has the following features:
1. Encode once, decode many time: the basic goal VBM tries to achieve,
2. Variable bitrate playback: by indicating the decoding bitrate of every frame, decoder can achieve variable bitrate playback in frame scale,
3. Real-time encoding and decoding.

It is noted that the VBM coder has NO
1. Psychoaoustic model: there is no perceptual controlling in the current implement,
2. Window switch: there is no attack detection to control long/short window switch. Yes, there is one single frame size.