详述主流浏览器的HTML5音频支持情况

作者：Chris Khoo

叙述HTML5音频支持状态糟糕的文章已有很多。事实就是如此，所以我不会在此赘述这一观点。相反，我主要着眼于开发者在特定平台中将会遇到的问题及潜在解决方式。

HTML5 audio from codecanyon.ne

table

上表总结了网页浏览器当前的市场份额。Internet Explorer依然是主要的桌面浏览器，紧随其后的是Chrome和Firefox。在手机领域中，Safari主导市场，这主要归功于强大的iOS品牌，紧随其后的是Android。因此，我们将照此顺序逐一进行论述。

给刚着手植入音频内容的开发者的建议：建议在音频层上采用SoundManager 2。目前，这是最佳Javascript音频库。植入过程非常简单，API非常整洁，能够在BSD Open Source许可下获得。此外，这一工具的过人之处在于，提供免费第三方代码更新和维护。

Internet Explorer

IE 8及其以下的版本不支持HTML5画布和音频，所以这又回到：图像部分基于DOM操作，音频部分通过Flash技术。采用SoundManager 2能够让你在于旧版IE浏览器中支持HTML5音频的过程中省下很多麻烦。

IE 9则完全不同。HTML5画布和音频表现突出。若微软放弃Win XP OS，IE 9的使用率将大幅提高。

这将是微软的明智之举。

Chrome

Chrome 18及更高版本支持HTML5音频和画布。但HTML5音频只有在网页服务器支持部分下载的情况下才能够顺利运作。这一问题的症状有：

* 无法重播音频

* 无法控制重播位置

* 音频播放一次后停止，但“结束”事件没被激活

解决这一问题最简单的方式是，在网页服务器上启动远程请求。注意，Google App Engine并不支持远程请求，但我们可以通过执行支持远程请求的文件服务程式解决这一问题。

另一避开这一问题的方法是，避免采用内置循环函数，通过load()函数“倒回”，在此播放音频。这能够解决问题，但会提高网页服务器的负荷。当加载函数在音频实例中被调用时，网页浏览器就从网页服务器上提取音频数据。

另一选择就是运用Web Audio API。主要缺点是，目前只有Chrome支持Web Audio API，而且只支持版本18或更高版本。它的突出优点是，Web Audio API通过提供音量和摇摄控制及即时过滤，解决HTML5音频的所有缺点。

Safari

Safari和Chrome都是基于Webkit的浏览器，二者存在类似的优缺点。和Chrome一样，Safari支持HTML5画布和音频，但Safari不支持Google Web Audio API。

遗憾的是，Safari也有和Safari类似的缺陷——它和不支持部分下载的网页服务器所提供的音频不同。Safari的症状截然不同：

* 少量/简短音频没有问题

* 冗长音频就无法播放，会发送音频文件格式受损的错误提示

解决这一问题最简单的方式是，启用网页服务器的部分下载功能。补救方法具体查看Chrome版块。

Firefox

Firefox 3.6及更高版本支持HTML5画布和音频。但Firefox 3.6的音频支持存在许多漏洞——简短音频无法播放，中长音频没有问题。如果你寻求更高级的音频支持，Mozilla基金会目前正在执行自己的Web Audio API——Audio Data API。

iOS移动平台（Safari移动平台）

Safari Mobile包含桌面浏览器的所有优缺点，此外它还有一个限制条件—–所有HTML5音频必须通过用户互动激活。这一限制条件带来两个主要弊端。

首先，这一限制条件阻止音频进行预先缓存/预先加载。因此，任何等待音频“canplaythrough”事件，以探测预先加载音频的应用就会陷入挂起状态。其次，激活音频回放事件非常棘手，因为苹果极力抵制非用户激活的音频回放——这一限制条件一度有个变通方案：通过Javascript模拟点击事件，但这一方法自iOS 4.2.x起就不再适用。

最后，Flash音频回放技巧不适用iOS平台是因为iOS不支持Flash技术。

iOS只有两个选项——禁止所有音频，继续通过网页浏览器提供应用；或者保留所有音频，通过appMobi、PhoneGap或Appcelerator以原生应用形式发行HTML5应用。关于游戏开发，我建议采用appMobi，因为它有画布加速器功能。

Android（内置浏览器）

只要你的OS平台不那么分散。存在许多Android版本使得HTML5音频支持很难有最终定论。关于目前Android OS存在多少变体，不妨查看YUI Theatre的视频“Scaling Mobile with YUI”。在22分处，解说者呈现一个包含目前市场上Android OS版本不完全列表的幻灯片。

这些是平台的常见音频特点：

* Android 2.x似乎支持HTML5音频，但它无法播放音频。幸运的是，应用继续顺利运作——所有音频函数调用返回适当结果，加载/缓存事件被合理激活。

* ICS (Android 4.x)支持HTML5音频，它能够播放音频。但回放只限于一次一个声音，最近播放的音频会代替所有之前的音频回放。

我没有测试Android 3.x的HTML5音频性能。

幸运的是，Android支持Flash整合，所以回放Flash音频具有可行性。尽管如此，Flash是个可选谷歌应用，因此并非所有Android手机都安装了这一应用。遗憾的是，关于手机Flash市场的渗透情况，我没有任何数据。无论如何，这一方法并不推荐，因为Adobe已放弃支持手机Flash技术，所以在不久的将来，这多半会消失。

确保提供适当音频支持的最佳方式就是走本地路线，通过appMobi、PhoneGap或Appcelerator发布HTML5应用。关于游戏开发，我推荐appMobi，因为它计划在Android平台添加加速画布支持（游戏邦注：这一功能目前处在Beta阶段）。

总结

通往HTML5音频之路布满荆棘。我建议采用SoundManager 2，这能够帮你省下很多麻烦。关于手机平台，情况就不那么明朗。不妨考虑走本地路线，通过asappMobi、PhoneGap或Appcelerator之类的HTML5原生应用平台以原生应用形式发行HTML5应用。关于游戏开发，目前的最佳HTML5原生应用平台是appMobi。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

The HTML5 audio troubleshooting guide

by Chris Khoo

Much has been written about the woeful state of HTML5 audio support.  It is what it is, so I won’t bother retreading over the same points in this article. Rather, I’m going to focus on the issues a developer may encounter on a per platform basis, and the potential solutions for them.

Desktop Web Browser Market Share Browser

Browser Version                  Total Market Share

Microsoft Internet Explorer 8.0      26.92%

Microsoft Internet Explorer 9.0      17.00%

Firefox 12                           11.15%

Chrome 18.0                           9.10%

Chrome 19.0                           7.41%

Microsoft Internet Explorer 6.0       6.17%

Safari 5.1                            3.48%

Microsoft Internet Explorer 7.0       3.43%

Firefox 11                            2.24%

Mobile Web Browser Market Share

Browser Version            Total Market Share

Safari 5.1                      44.99%

Android Browser 4.0             18.96%

Safari 5.0                      15.13%

Opera Mini 4.2                  4.52%

Opera Mini 4.1                  2.11%

The tables above summarize the web browser market share today (courtesy ofNetMarketShare). Internet Explorer is still the leading desktop web browser followed by Chrome and Firefox. In the mobile market, Safari (unsurprisingly) dominates the market on account of the strong iOS brand followed by Android. Therefore, that’s the order that we’ll be covering the browsers.

A sidenote for developers just starting to integrate audio – I highly recommend using SoundManager 2 for the audio layer.  Currently, it’s the best Javascript sound library available. Integration is painless, the API is clean, and it’s available under the BSD Open Source license. Besides, nothing beats having free third party code update and maintenance.

Internet Explorer

IE 8 and below lack HTML5 canvas and audio support so expect to fallback to DOM manipulation for visuals and Flash for audio. Using SoundManager 2 will save you a lot of the headache in trying to support HTML5 audio in the older IE browsers.

IE 9 is a whole different ball game. HTML5 canvas and audio work perfectly. Expect the IE 9 adoption rate to sky rocket when Microsoft sunsets the Win XP OS.

Kudos to Microsoft for getting it right (finally).

Chrome

Chrome version 18 and higher supports HTML5 audio and canvas. However, HTML5 audio will only function correctly if the web server supports partial downloading (ranged requests). Symptoms of this issue are:

* Unable to replay sound

* Unable to control playback position

* Sound plays once then stops, but the ‘ended’ event is not fired

The easiest way to resolve this is to enable ranged requests on the web server. Please note that Google App Engine does not support ranged requests, but it is possible to work around the issue by implementing a file serving servlet which supports ranged request. The Balus C Code website contains an article describing one possible servlet implementation.

Another way to circumvent this issue is to avoid using the built-in loop functionality and to use the load() function to “rewind” and play sounds again. This will resolve the problem but increases the load on the web server. Every time load is called on an audio instance, the web browser will fetch the audio data from the web server.

Another alternative is to use the Web Audio API.  The major drawback is that the Web Audio API is currently supported exclusively by Chrome and only in versions 18 or higher. The major advantage is that the Web Audio API addresses all of HTML5 audio shortcomings by providing volume and pan controls, and real-time filtering.

Safari

As Safari and Chrome are both Webkit based browsers, both share similar advantages and drawbacks. Like Chrome, Safari supports HTML5 canvas and HTML5 audio, however Safari does not support the Google Web Audio API.

Unfortunately, Safari has similar drawbacks to Chrome – it doesn’t like audio served from  a web server lacking partial download (ranged requests) support. The symptoms on Safari are different. They are:

* Small/short sounds play just fine

* Long sounds don’t play at all and throw an error that the sound file format is corrupted.

The easiest way to address this issue is to enable partial downloading on the web server. Please refer to the Chrome section for possible ways of remedying this situation

Chrome

Firefox 3.6 and higher support HTML5 canvas and audio. However, Firefox 3.6′s audio support is buggy – short sounds do not play but medium length sounds (or longer) play just fine. If you’re looking for more advanced audio control, the Mozilla foundation is currently implementing its own version of the Web Audio API called the Audio Data API.

iOS mobile platform (Safari mobile)

Safari Mobile has all the strengths and weaknesses of its desktop brethren but introduces a new limitation – all HTML5 audio must be triggered through a user interaction. There are two major drawbacks caused by the limitation.

First, the restriction prevents  sounds from precaching/preloading. As a result, any application waiting for the audio ‘canplaythrough’ event to detect audio preloading will hang indefinitely. Second, triggering sound playback is tricky at best as Apple is actively working to prevent non-user triggered audio playback – at one point, there was a workaround for this limitation by simulating a click event through Javascript, but the workaround no longer works as of iOS 4.2.x.

Finally, the Flash audio fallback trick will not work on the iOS because the iOS does not support Flash.

There are really only two options on the iOS – either (1) disable all sounds and continue serving the app through the web browser, or (2) keep all the sounds and publish the HTML5 app as a native app via appMobi, PhoneGap, or Appcelerator. For game development, my recommendation is appMobi because of its canvas acceleration feature.

Android (built-in browser)

Oh, Android… if only your OS platform wasn’t as splintered. The numerous Android versions out there make it hard to give a definitive answer on HTML5 audio support. For an idea of how many existing variants of the Android OS out there, watch the YUI Theatre video ‘Scaling Mobile with YUI’. At the 22 minute marker, the speaker shows a slide containing a non-exhaustive list of Android OS versions in the market.

These are the platform’s general audio characteristics:

* Android 2.x seems to support HTML5 audio but it will not play the sounds. Fortunately, the application continues to function normally – all audio function calls return appropriate results and load/cache events fire properly.

* ICS (Android 4.x) supports HTML5 audio and it will play sounds. However, playback is limited to only one sound at a time with the latest played sounds superceding all previous sound playback.

I did not test out Android 3.x HTML5 audio capability.

Fortunately, Android does support Flash integration so it is possible to fall back to Flash audio. With that said, Flash is an optional Google app so not all Android phones will have it installed. Unfortunately, I don’t have any statistics on the mobile Flash market penetration. Regardless, this approach is not recommended as Adobe has dropped mobile Flash support (yes, I’m still somewhat bitter about this), so expect it to go away sometime in the near future

The best approach to ensure proper audio support to go native and publish the HTML5 app via appMobi, PhoneGap, or Appcelerator. For game development, my recommendation is appMobi because of its plan to add accelerated canvas support for the Android. The feature is currently in the Beta stage.

Conclusion

The road to HTML5 audio is rife with pain. My recommendation is to save yourself a heap of trouble and use SoundManager 2 for the audio layer. For the mobile platforms, things are less clearcut. Consider going native and publishing the HTML5 app as a native app using an HTML5 native app platform such asappMobi, PhoneGap, or Appcelerator. For game development, the best HTML5 native app platform today is appMobi.（Source： gamasutra）