2009年3月19日 星期四

騰雲駕霧程式競賽

睽違已久的趨勢程式競賽又再度出現了,對當時還是大學生的我而言,趨勢的比賽是一個大消息,開口粥大師最近較忙,就由小弟我來代貼有關比賽的資訊。注意!3/24(二) 12:20-13:30 在成大資工4263有舉辦說明會。另外請隨時注意官方blog所公佈的 training course 消息。

以下是資訊來源:

騰雲駕霧程式競賽官網: http://www.trend.org/fd/tabid/66/Default.aspx

騰雲駕霧程式競賽官方 blog: http://www.wretch.cc/blog/trendnop09

騰雲駕霧程式競賽官方 blog: http://keikoblog.blogspot.com/2009/03/blog-post_10.html

image

我們公司辦的比賽,有興趣的人,尤其是學長弟妹可以參加唷!節錄一些重點:

「騰雲駕霧程式競賽」由趨勢科技主辦,IBM生物資訊研發中心協辦,該單位將提供硬體設備贊助。競賽籌備小組自3月10日起將至台北科大、台大、清大、交大等9所大專院校進行巡迴說明…

  • 說明會時間地點

    3/11(二) 12:20-13:30
    北科大
    綜合科館第三演講廳

    3/11(三) 13:00-14:00
    台大
    資工系 102

    3/12(四) 12:10-13:20
    台科大
    IB510

    3/16(一) 12:20-13:30
    中山
    電資大樓 F1001

    3/17(二) 11:00-12:00
    中央
    工五館 207

    3/18(三) 15:00-16:00
    清大
    資電館 127

    3/19(四) 12:20-13:30
    交大
    工三 122

    3/23(一) 14:00-16:00
    中正
    地震館 215

    3/24(二) 12:20-13:30
    成大
    成大資工 4263

  • 報名資格
    大學生、研究生、每隊四人(不多不少唷),可跨校!
  • 報名
    3/20-5/15:將開放網路報名,6月份將安排參賽者接受第一階段的網路遠距教學!
  • 比賽方式
    • 初賽
      7/1:網路公佈題目。
      7/8:00:00 停止收件。
      7/22:公佈入圍名單。
    • 決賽訓練課程
      7/30 ~ 7/31:到趨勢上課!
    • 決賽
      8/18 ~ 8/19:決賽入圍。今年也有可能不會在台北士林劍潭青年活動中心,會改去 IBM 生物資訊研發中心吧?機器都在那邊,或是要很炫的自己遠端 deploy 到伺服器海中,那就不必到現場了!
  • 頒獎
    8/20:頒獎。往年頒獎典禮都蠻有心的,會找飯店,以前有去過晶華酒店,典禮有簡單的點心、可邀請家人朋友、找記者來採訪(不過記者好像都不會來-_-|)
  • 獎項(這好像是最重要的)
    1st:NT$500,000
    2nd:NT$300,000
    3rd:NT$200,000
    4th:NT$150,000
    5th:NT$100,000
    6th ~ 10th:NT$50,000
    預聘書現在只給前三名了
  • 題目
    好像沒提到,但是跟雲端運算有關就是!
  • 競賽網站
    http://www.trend.org/fd/tabid/66/Default.aspx
  • 附註
    比賽中會需要各式各樣的人,寫 UI、寫程式、寫文件、上台 presentation、找 bug、做 testing 都會,所以記得要把團隊技能平均問題,不要只點某一、兩樣技能唷!

我是工作人員,不管有什麼疑難雜症、難以啟齒需要匿名的問題,我都可以代為傳達唷!

2009年3月18日 星期三

在 blog 上貼 YouTube

網友 Alvin 最近詢問怎麼在 blog 上嵌入 YouTube 一類的元件,所以就來跟大家介紹一下,順便騙騙文章數,掩飾一下自己江郎才盡了…

步驟一

YouTube 之類的服務都有提供物件語法給大家複製到自己的網頁上,參考下圖可以看到網頁有一區標示著嵌入

ScreenHunter_01 Mar. 18 21.28

步驟二

滑鼠移過去,還會發現有自訂的功能。使用者可以根據自己的需求調整,調整後,就是把 <object> …開頭的語法複製起來。image

步驟三

開啟自己 blog 文章編輯的 html 模式,以 WLW 為例,就是切換到程式碼模式。 接著就勇敢的貼上吧!

ScreenHunter_04 Mar. 18 21.55

成果

最後,就可以看到成果了!

其他

其他像是 mp3, quicktime 等格式的多媒體資料,基本上只要 host 有提供 object 來嵌入,都可以在網頁上產生美美的元件。

結語

ㄜ,感覺教學最後就要來個結語,那就: Yes, We Can!

HHT – Hilbert Huang Transform

Key words : Hilbert-Huang transform, Hilbert spectrum, Hilbert transform

這個演算法,是利用Empirical Mode Decomposition(EMD)將原訊號拆解成數個Intrinsic Mode Functions (IMF)。今天我整理一下以音高為D4的小提琴為輸入所做的實驗結果。



整個 Hilbert Analysis流程如下圖所示(謝志敏, 2007)。

image

image image

一開始先做 EMD,先找出整段訊號的 local maxima & minima,然後用 cubic spline line分別造出envolope,最後再將這兩個envelope取平均,即為第一個分量;依此類推,直到這個平均後的值趨近於水平線時,該訊號即為第一個 IMF。收斂條件依定義為一名為 SD 的式子,不過實驗的程式是執行 10 次 iterations。

小提琴做完的結果如下圖所示。由上至下依次為原音(當作是IMF 1)、IMF 2, 3, 4, 5, 6。音檔在這裡,可直接下載。

image

聽過音檔後,大家應該不難發現,IMF 2 的頻率較高,IMF 5 聽起來像是心跳聲,噗通一下就沒了。其實依傳統EMD作法,解出來的 IMF 順序,其瞬時頻率是由高往低的,有點類似像 band pass filter。由圖可知,IMF 4的頻率是最接近原音音高的地方,所以能量最大,而 IMF 5只剩起頭音的部份有聲音。

小結:

IMF 5 只有起頭音跟後面一小段(?)有訊號,可能會是我要做 noise modeling 時所需要的元素。而年前老師要我改變 maxima & minima envelope的擷取方式,希望能先抓出較完整的 sine wave,目前做出來效果並不理想,一來是envelope要抓得很完美不好做,二來是 IMF 依舊有從高頻先被取出來的特性。

投影片:下載

2009/02/20 Progressive Report

目前的實驗是先將頻率考慮進去,求得週期後,先從任意為起點,往後的 1 週期內找 local maximum,此點即為 peak value。下個起點,則由目前的 peak value 位置往後移動 2/3 週期,不直接移動一整個週期是怕有誤差,一直重複上列動作就可以找出所有 peak value;同理,也可以找出所有 valley value,最後結果如下。

1

上圖的藍色 envelope 是原訊號,紅色 envelope 則是有 peak & valley 為點作 spline function 而成的結果。將藍色減掉紅色,就是下圖的藍色。

從上圖來看,紅色 envelope 還滿貼近原訊號的,本以為扣掉後剩下的訊號會變很少,但事與願違。原因是出在 spline function 造出來後雖然很貼近,但仍有些區域是差得較遠的,紅直線跟青直線分別是原本的 peak & valley 所對照下來的位置,這兩個位置扣掉後都是 0 ,但其他位置卻有相差到 +1 / –1 的大小。

接下來,我將試著將半週期內所有的 peak & valley,套用 monotonic increasing/decreasing 的條件後再看看結果。

0225-Memo:

  • 觀察這個失敗的實驗,看看是否做無限迴圈後能擷取出f0。
  • 找論文看有沒有人用HHT做修改來分析聲音。

2009/03/03 Progressive Report

我先給大家看一下上次提到的「半週期內所有的 peak & valley,套用 monotonic increasing/decreasing 的條件」的結果。

1

這個訊號的週期約在148-150個sample左右,f0差不多在297-300。大家可觀察到無論是紅點(peak)還是黑點(valley),從最大值開始算半個週期內皆呈現 monotonic decreasing,下個半週期則呈現 monotonic increasing。粉紅色線為紅點及黑點所建連線的平均線。

不過,藍線減掉紅線的結果如下圖。

2

很明顯的,300hz 的波形還是有留一些能量,原因是因為粉紅色線的極值沒有緊緊貼在原訊號的極值上,導致減掉後仍留有能量,相較於其他波形的能量甚至還滿大的。

隔天,我試著將原訊號的極值同時加到peak/valley兩邊的陣列資料中,這樣照 spline function 時至少在極值的地方會重疊。結果如下圖。

image

原訊號的頻譜:                             平均線的頻譜:

image image

原訊號 - 平均線

image

已知問題及解法:

做完第一次後,剩下的訊號其300Hz, 600Hz, 900Hz 的能量明顯掉了許多,因此第二次再做時,不能再以原本的週期來作為 monotonic inc/dec 的判斷,否則造出來的spline function會有爆走問題,如下圖。解法: 先用簡單的pitch detection算出目前能量較大的週期後再做第二次實驗。

第二次                                       第三次

image image

Bug: 找出在做第一次時16000-21000, 25000-33000 區域的振幅大小有一點小爆走的原因。(而且還只有下方有爆走)

image

2009/03/06

上面的Bug 解決了,原因出在有些區域的「最小極」沒有被列入spline function points,導致造出來的波形在某些情況下會有點誤差。

雖然問題解了,可是出來的結果還是跟上圖差不多,為了方便解釋一下原因請看下圖。

image

圖中有兩個紅圈圈,紅點跟黑點有全部找到,可是左紅圈內的結果卻比右紅圈內的結果較好,why? 其實這就是訊號的特性,左紅圈內的黑點較集中,所以 spline function 造出來的envelope較貼近原訊號,但右紅圈內的黑點較分散,所以會有波形振幅不一的情況。

這個「現象」目前我不將它當成「問題」,之前之所以成為「問題」的原因是在16000-18000這段的頻譜,在經過三、四次loop後高頻的能量不減反增,但現今已經沒這問題。這裡補一下圖:

0303版,第四個loop後剩下的波形,及27825點該frame的頻譜:

image image

0306版的:

image image

我將繼續往下做,讓週期是 adaptive 的,再看看結果如何。

2009/03/10

老師在3/7的留言中提出一個疑問: 「經過第一次decomposition後, peaks降低了, 可是noise floor也變大了. 這是甚麼原因呢?」

我紀錄一下大家的看法。

老師:

Spline function 是採用 non-uniform sampling 的作法,跟 Fourier Transform 觀念背道而馳,因而可能造成這種現象。(ps. 這邊不太懂 non-uniform sampling 可能造成哪些結果)

Spline function本身main lobe不夠尖,side lobe也不夠小,換成 sinc function 可能會比較好。

DNA:

有時候別太相信 Cooledit …,它的db scale不知道到底對象是誰。

Showmin:

我翻了下課本,發現兩個訊號點對點相加時,能量本來就有可能會大於在頻率上的點對點相加,只要兩者 FFT 出來的實部係數or虛部係數異號。

|x1| + |x2| >= |x1+x2|

小結: 這種現象會不會影響結果還不知道,先紀錄一下。

最後貼一張圖,我在範圍介於 +-10 之間造一個 sinc(x),而且只取15點。然後,用這15點座標來分別造出新的 sinc 跟 spline,出來的結果如上圖,spline function較平緩。下圖則是上圖做 abs(fft(x)) 的結果。

sinc spline

2009/03/17

1. ACF用來判斷pitch period不適用於我們的實驗,因為我們無法將某一pitch的能量完全扣除乾淨。

2. 接著我讓pitch period隨著loop數減少,前兩圈的結果如下。

image image

即使我將起始點位移的距離改小,還是有一些點沒有找到。

image

是的,這是bug,解決方法很簡單:在找一個週期內的極值時,順手將這個值加到 set 中。之前是只有在判斷 monotonic increasing/decreasing 時才會加進去。當然,在這種情況下極值可能會被加到不只一次,但不影響程式執行的。最新結果如下:

image

3. spline function effect

這個問題前面就有提過,就是兩個點距離如果有點遠,但值卻差不多大,則spline function會凸出來。上面的結果雖是正常,但只要換到其他時間點來觀察,依然有問題。

image

這個圖的點其實都有找對了,但卻因 spline function 的特性造成有凸出來的 effect。

 

 

投影片下載:這裡

DNA:

何不試著在原訊號後面較穩定的地方找一段完整週期訊號,以此為 template,然後將原訊號拿來減掉這個template,template的能量可隨著該frame而調整。

2009/03/18

由上面第3點的結果我們可以發現,在訊號的能量都差不多時(noise-like),用新方法是滿容易因spline function爆走的,所以老師提供一個實驗方式,要我第一圈先用新方法,第二圈用EMD,看看做完EMD後能否再讓訊號「有起伏」。這個答案是肯定的,請看圖。

第1圈用新方法求得的平均線。

image

第二圈改用EMD,下圖為EMD做10次後的結果。

image

做完EMD後,用原訊號扣除上圖即為下圖。很明顯下圖的波形「有起伏」,那理論上再回頭用新方法來找應該很棒,可是為何平均線會找得沒有第一次好呢?這是因為第三圈的週期只剩 150/3 = 50,點的距離較寬而無法將最大值納入 min set,反之亦然,也無法將最小值納入 min set,所以平均線雖然沒有爆走,但卻沒那麼貼。

image

如果週期維持在150的話就會好多了,當然一樣會有spline function effect,而且點距離越寬越明顯。

image

第四圈,再做 EMD。

image

第五圈,再回頭用新方法。此時可以發現用新方法或用 EMD 效果都差不多了。

image

目前有些疑問,再找時間跟老師討論。

OpenCL

看來nVidia有意要開放OpenCL變成Open Standard
不過當然是為了賺錢.... Maket Builder 這個字還真有意思

http://www.channelregister.co.uk/2009/03/17/opencl_demo/

2009年3月17日 星期二

Bus Protocol In TLM2 - 宗胤

我大概訂了系統所要用的Protocol,基本上我只是遵循TLM2中所定義的Base Protocol來實作系統的Protocol,另外我使用AT的Coding Style來實作這個Bus。

而TLM的Base Protocol的在AT中的實作方法有分許多種,如backward path、return path、timing annotation等。我所用的是如下圖所示的timing annotation:

Timing annotation在timing annotation中,initiator(target)會透過nb_transport_fw(nb_transport_bw)傳給target(initiator)一個事先定義好的delay,告訴target(initiator)在經過delay後某個phase才開始。

所以由上圖可看到一開始initiator傳了10ns到target,接著target會將收到的payload放到一個payload event queue中,經過10ns才會開始處理這次的傳輸(即Begin_Req開始)。而下面的End_Req也是一樣。

系統架構:

image

整個系統流程大概如下:

  1. initiator設定好payload的參數,並且設定phase為Begin_Req和決定delay後利用nb_transport_fw送至bus。
  2. bus根據payload中的addr將payload送到對應的target
  3. target收到payload後,等待delay的時間後,設定phase為End_Req和設定delay,再使用nb_transport_bw將回應送至bus
  4. bus再將回應送到對應的initiator
  5. initiator收到回應,等待delay時間後,完成此次的Request
  6. 當target完成payload所指示的指令後,開始Begin_Resp的phase,整個流程基本上與Req相似,只有傳輸的方向相反而已

基本上我會照這個來implment整個系統。

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

03/17

補上Coware上關於Bus的分析工具:

Bus Contention Statistics & Bus Contention Trace

1

Connection Bus Utilization & Master Wait Total & Master Wait Trace

2

Transation Counts &  Transation Duration

3

Connection Bus Wait & Transation Throughputs & Transation Trace

4

接著關於今天提出了問題:

  1. 關於Delay Time,由於沒有Spec之類的東西,所以我就自己定Delay time的大小
  2. 然後關於Bus的Implementation,有些錯誤的地方,如queue payload會將它更正

今天的投影片