HTML5 音頻 API 到底該有多複雜?

答應過說這次要提出比較會被稱為 HTML5 內容的討論的 :p

這次在擁抱 HTML5 裡面講遊戲的很多,而對於製作遊戲來說,我們畫圖有
<canvas> 了,但是音頻的操作還沒有一個統一的標準。剛好最近在試圖了解
Mozilla 跟 Google 提出的音頻/音效 API 的差異的時候,整理了一個音頻 API
的 wiki 頁面[1],給各位參考,說不定下次就會見到使用這些 API 的演示了。

[1] http://www.w3.org/html/ig/zh/wiki/音頻_API

Mozilla 的 Audio Data API(中文說明已翻譯,請看上面 wiki 頁面) 跟
Google 提出的 Web Audio API 的差別,簡單的講在於 Audio Data API 非常的陽
春,它預期使用者使用全部使用 JS 處理音訊資料。另一方面 Web Audio API 則
是預定義了很多音訊處理部件,而預期使用者將部件排列、組合起來,而這些部件
很多是用瀏覽器內部的 C++ 甚至是 Assembly 寫的。兩邊支持者的論點分別是:

== 支持 Audio Data API 的講法 ==
* JavaScript 已經非常快了,Web Audio API 那麼多 API 會讓瀏覽器之間達到兼
容花費非常多的時間
* Audio Data API 有重複利用 HTML5 <audio>、<video> 的 API ,Web Audio
API 很像是完全新的東西

== 支持 Web Audio API 的講法 ==
* 這種部件的架構有很高的擴展性,利用 JS 處理部件(JavaScriptAudioNode)
可以完全覆蓋 Audio Data API 的所有功能
* 對於遊戲支援來說,任何太差勁的延遲(latency),或是聲音的破裂(audio
glitch)都是不被允許的, Audio Data API 太簡單,沒考慮這些問題
* JS 雖然很快了,但是在低端的裝置還是不及原始代碼

關於最後一點,有不少 Audio Data API 的演示是有關於視覺化音頻的,而這些演
示都用的快速傅立葉轉換演算法都是用 JS 寫的。對於這些應用,這裡引入一段
Apple 的 HTML 工作組主席 Maciej Stachowiak 很有意思的講法:
[[
On many platforms, "native" FFTs are much faster than any possible C
implementation, let alone JS.
]][2]
(在很多平台上,「原始」的快速傅立葉轉換都比任何可能的 C 實作還快了,更
不用說 JS 了)

意思就是很多平台有一些對於聲音處理的硬體支援比 C 還快。這就讓我想到磊友
霏哥做的以 Symbian 為目標的 HTML5 遊戲瀏覽器說不定也可以以支援部份的 Web
Audio API 為目標。

[2] http://lists.w3.org/Archives/Public/public-xg-audio/2010Jun/0033

這邊希望各位 Flash 牛人在 wiki 頁面上貢獻一些這兩個的 API 中做不到的但是
Flash 做的到的事。也歡迎多加一點演示的連結(特別是中文朋友們做的),或是
也可以在討論頁面做各種討論,到底 HTML5 音頻 API 到底該有多複雜?

非常給力的小胖的演講中提到 Android 在即起直追,這個 Google 提出的 Web
Audio API 有可能會是其中之一!(雖然非常諷刺的,現在能玩 Web Audio API
的只有 Mac 版的 Chrome 11)

p.s. 也希望有誰整理一個 Canvas 2D 的類似的 wiki 頁面,可以把也是很牛
flashlizi 的 Canvas 程式庫 casualjs[3] 加進去!

[3] http://code.google.com/p/casualjs


此致

呂康豪(Kenny), 中文興趣小組W3C連絡人
推特: http://twitter.com/kanghaolu
噗浪: http://www.plurk.com/kennyluck
新浪微博: http://t.sina.com.cn/1950042164

Received on Sunday, 17 April 2011 09:31:45 UTC