12 ms·

The State of HTML5 Audio

109 points by sant0sk1 16y ago

dstein 16y ago
Mobile Safari Can't pre-load sound files, only plays one sound at a time, severe lag, timing issues, clicks & pops, completely ignores every other call to play a sound, doesn't support Ogg/Vorbis. Utterly useless for anything. Oh, and did I mention it doesn't support Ogg/Vorbis?* More specifically Apple has crippled the Audio API by disabling the autoplay option, and disabling the JavaScript .play() function. This makes it completely impossible to build web games, or web apps that have any sort of audio feedback in Safari on any iOS device. Presumably they've done this to prevent web games from becoming popular and eventually dethrone the App store.
- masklinn 16y ago
  > Presumably they've done this to prevent web games from becoming popular and eventually dethrone the App store. No. They've done this to prevent web sites from outputting sound when they're loading (or just as they're done loading). Your blind hatred is moronic.
  - trotsky 16y ago
    It seems obvious that Apple's interests don't coincide with fully functional cross platform mobile apps. Getting people to build with objective C and native code helps lock in and ensures that any sales go through their payment platform. If you don't think Apple has been moving in this way (anti-cross platform dev tools, requiring sales to use the iTunes payments) you simply haven't been paying honest attention.
    - e1ven 16y ago
      I understand that you're unhappy with Apple, but keep in mind that their original iPhone was HTML apps ONLY. Further, they continue run WebKit as an OSS project, and have worked to be accommodating to other mobile providers. The reason they dislike flash isn't some sort of inherent hatred, it's that it's outside their control. They can implement a HTML spec just as well as anyone else, and with Webkit, they can lead the way. Apple Wants to see a strong HTML web.
      - cookiecaper 16y ago
        >Apple Wants to see a strong HTML web. They want this as long as they are not the dominant platform. If MS and Apple swapped places tonight and Apple suddenly had 90%+ marketshare, it's likely that their strategies would flip just as fast, because it's the most profitable thing to do. Apple's interests are in ensuring that their platforms can run as much user-desired content as possible; they can do this by promoting cross-platform compatibility and interpreted code like JS and HTML. Microsoft has no need for this, since everything runs on Microsoft by default, because if it didn't, you'd miss out on 90%+ of your potential market. Instead, Microsoft's interests are opposite; they want to do everything they can to ensure that Windows is still required for any and all meaningful usage. This is the major point of IE; do enough to mostly work, but break compatibility where you can get away with it so that developers can't forget about Windows and IE. They also hope, though the environment isn't appropriate for this to work anymore, that IE will be your sole development platform and that considering the time it takes to make stuff work in IE, you will just leave things broken in all other browsers, further solidifying the MS lock-in. Lock-in is the holy grail for the software vendor. Apple is putting this in place as best as they can in the markets they control, and they are trying to ensure that MS doesn't lock them out of the desktop game, because they're still vulnerable believe it or not. MS is trying to ensure that Windows' death grip remains in place FOR. EVER., just as Apple wants iPhone/iPod to do the same.
        masklinn 16y ago
        > Lock-in is the holy grail for the software vendor. Apple is not a software vendor.
        bane 16y ago
        http://store.apple.com/us/browse/home/shop_mac/software/apple?mco=MTM3ODExMzA http://store.apple.com/us/browse/home/shop_mac/software/appl...
        cookiecaper 16y ago
        They are a software vendor, and by vendor I mean producer. They don't not become a software vendor because they bundle the software and hardware together. They may make money on their hardware which is great for them, but it doesn't change the fact that OS X, iTunes, and the others, like all other software platforms, want lock-in; Apple merely wants to lock you in to the hardware too, so they use the software platforms to do that.
    - masklinn 16y ago
      > It seems obvious that Apple's interests don't coincide with fully functional cross platform mobile apps. No, it is not that obvious at all. May I remind you that Apple introduced the iOS SDK, spearheads what is usually recognized as the finest rendering engine out there and built what was the first mobile device actually able to surf the web? And that they have shown no will or wish to backtrack on any of these, doubling down instead? There is something much, much simpler to these issues: 1. Jobs's Apple will never again live and die at the whim of a third party. They suffered greatly during the Classic-OSX transition because Apple had lost control of the development platform itself (which was basically owned by Metrowerk and its CodeWarrior) 2. Jobs's Apple takes decisions it thinks benefit its customers and its customers are always its users. Now they may be wrong on that, and they may be misguided, but time and time again you can (pretty easily) explain the decisions of Jobs's Apple either as trying to avoid losing their platform to a third party or trying to make their user's experience life better. With web browser they fully control the platform. Hell, they control what can be argued the best web platform available (Google's Chrome is giving them a run for their money, in no small part by building upon their work). They don't fear people using their web browser, they wouldn't have built Canvas if they did (why not leave it out as SVG? Slow, hard to use and not a threat at all), they wouldn't be implementing WebGL, they wouldn't spearheads CSS animations and transitions and all the stuff that can make web applications snazzier and cleaner, they wouldn't have the engine with the best HTML5 support by far. Web stuff is not a threat, because they can have the best, shiniest and most advanced web stuff and they control all of it (number of full rendering engines allowed on iOS devices? one. Nobody else is allowed to ship a JS interpreter, therefore no full-blown web browser can avoid using the Webkit that ships with it and is fully built by Apple). Apple doesn't fundamentally mind or care for cross-platform mobile apps, what they fear is a third party's cross platform toolkit taking preeminence over their own tool and deciding of their platform's future. That is why they banned flash (also, because flash is a piece of shit). > Getting people to build with objective C and native code helps lock in That only works because you assert Apple wants to lock users in. > and ensures that any sales go through their payment platform. Cross-platform tools would have the exact same restriction or face bans. iTunes payment mandate is trivially explained through integration and user-experience (did you know that Apple's subscriptions services makes user information availability to magazines opt-in by the user, whereas just about every other service makes it opt-out if opt-able at all? That's because to Apple the device owner is the customer, to just about every other publisher the magazine is the customer). > If you don't think Apple has been moving in this way (anti-cross platform dev tools, requiring sales to use the iTunes payments) you simply haven't been paying honest attention. Either that, or I have not been wearing hate-shaped glasses. But really, I wonder why I bother with all that typing. I should know by now that HN's view of Apple is the same as /r/tech's: a bashing wankfest.
  - dstein 16y ago
    No. They've done this to prevent web sites from outputting sound when they're loading (or just as they're done loading). The Audio API's .play() method is now always disabled. It was working on the iPad iOS 4.1 only through a hack, but Apple closed that hole in 4.2. I have no hatred of Apple, I own plenty of Apple products, but absurd strategic crippling of standards does not help my impression of them. It just wreaks of Microsoft-style embrace, extend, extinguish.
    - masklinn 16y ago
      > The Audio API's .play() method is now always disabled. Well… yeah, when would you want to enable it in order for the user to always have control over the sound?
      - dstein 16y ago
        I've made my point clear. If you think web browsers should not have the ability to play any audio that's a different topic than whether an OEM gets to pick and choose which parts of a standard to implement and which devices can support it. This is exactly what made the IE web development days so particularly maddening.
  - ootachi 16y ago
    The author addresses that in the post: "I've heard some arguments that it is crippled on purpose, because you don't want a website to start blaring music at you as soon as you open it. Fine, I understand that argument. But why not ask the user for permission to play audio and then do it right? It's already been done with Geo Location and Storage."
    - deleted 16y ago
      [deleted]
- LaGrange 16y ago
  Ahahahaha no. Even if that's true, I, for one, despise the idea of any kind of audio autoplay for the web, be that flash or html5. If that breaks web games -- tough luck. I might be OK with some kind of whitelist, though -- same way it works e.g. for large off-line storage. But I like my games and audio editing software native anyway, thankyouverymuch.
  - dstein 16y ago
    >If that breaks web games -- tough luck. It's worse than that, it breaks the standard. Audio API can no longer be used reliably if a major portion of the audience can't utilize it. Remember when days when one major heavyweight would refuse to follow standardized web protocols? You know, like how SVG was standardized in 2001 and 10 years later can still not be used reliably. Stuff like that needs to stop.
    - LaGrange 16y ago
      Well, if the standard allows autoplay without user consent then it's broken. Just because a standard is doesn't mean everyone should follow it. It should be followed when it's a good standard, and in this case it's arguable.
      - smackfu 16y ago
        So IE can not follow the parts of the standards they don't like, and that's cool with you now? It's a pretty silly position to take.
      - jdc 16y ago
        I imagine a user consent message in the form of Firefox's XPI "Allow/Deny" bar would work well for this.
    - yuhong 16y ago
      >You know, like how SVG was standardized in 2001 and 10 years later can still not be used reliably. And XHTML too.
- newhouseb 16y ago
  I think the official reason (I read somewhere in documentation) is because they don't want web sites to suck up mobile bandwidth by automatically streaming stuff. You can have videos autoplay, yes, but videos you can overlay with controls, whereas audio can be integrated into an interface in such a way that the user has no means to stop playback.
mambodog 16y ago
I hope for the day when the Webkit Web Audio API[1] or something like it is widely available so we can build rich audio apps like Audiotool[2] without relying on Flash. [1] http://chromium.googlecode.com/svn/trunk/samples/audio/index.html http://chromium.googlecode.com/svn/trunk/samples/audio/index... [2] http://audiotool.com/app http://audiotool.com/app [SWF]
mithaler 16y ago
Contrary to his claims, his test case seems to work mostly fine in Chrome 10.0.648.127 (beta) for me. I haven't tried the dev channel version though. Firefox doesn't appear to be working well at all, in either 3.6.16pre or 4.0b13 (but those are both unstable versions, so I'll withhold judgment). All of those were tested on Ubuntu. Regardless, he's definitely made his point well (and my setup showing different but similarly bad results from his only proves his point): support for the <audio> tag is not really as solved as browser manufacturers are claiming, and is not currently a suitable competitor to Flash. Direct link to test: http://www.phoboslab.org/files/html5audio/ http://www.phoboslab.org/files/html5audio/
gmac 16y ago
In summary: "there's some profanity ahead because HTML5 Audio is still that fucked up". My experience is entirely aligned. I was trying to use <audio> earlier this week for an incredibly simple task (occasionally play a 0.5s notification sound). The only thing that worked reliably was Chrome (9) with a data: URI. FF3.6 (or Chrome with a normal URI) would only play the sound once, and Safari wouldn't play it at all. (These are all the Mac versions, and I didn't test Opera).
transmit101 16y ago
A lot of discussion about the demise of Flash is focused on how CSS and JavaScript can now create equally pretty-looking websites, which is fair enough. But take it from a long-time audio developer: HTML5 audio is essentially useless for creating web applications involving almost any kind of audio. Even Firefox, which has the best HTML5 support so far, offers absolutely nothing like what is possible using the combination of a Flash client and a dedicated streaming server. Flash might have a lot of bad points (which I'd be the first to call out) but RTMP audio (which also handles both video and arbitrary data) really isn't its worst feature, and for this reason alone its going to be a significant part of the internet for many years to come.
- Derbasti 16y ago
  I totally agree that for video/audio players, Flash is a good technology (if hardware support is enabled and Flash is properly sandboxed). Flash is platform independant, needs no pre-installed codecs and can be easily blocked. None of this is true for any native audio/video tag.
- aufreak3 16y ago
  Not quite true. If you look at audio in HTML only through the lens of the <audio> tag, you're right. Some of the work-in-progress JS audio API stuff that doesn't depend on the audio tag rocks, even right now, in the dev builds. The future looks brighter than ever without Flash imo. http://chromium.googlecode.com/svn/trunk/samples/audio/index.html http://chromium.googlecode.com/svn/trunk/samples/audio/index... edit: The in-progress spec - http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html http://chromium.googlecode.com/svn/trunk/samples/audio/speci...
mckoss 16y ago
I don't give a shit anymore about this stupid piece of crap that Microsoft calls a Browser and throws out a release for every 3 years, just in time to not let it fade out completely but annoy web developers for more years to come. I can relate to this feeling.
asuth 16y ago
We've been using SoundManager 2 on quizlet.com for playing audio clips. We're not just playing long music clips in the background, so it's essential to have all the precise APIs for preloading, playing, and firing callbacks when sound is done playing. It handles all the browser deficiencies very elegantly, either with HTML5 or flash. Also, it's just 10k of js (gzipped) so it's pretty lightweight. link: http://www.schillmania.com/projects/soundmanager2/ http://www.schillmania.com/projects/soundmanager2/
- JSig 16y ago
  I'm using sound manager on http://hackernewsradio.com http://hackernewsradio.com as well. Right now I am just forcing flash. I had too many problems with html5 audio. I really wanted speex encoded audio but that is not an option. If I remember correctly Opera handled streaming speex/ogg like a champ. Firefox may have worked... I can't remember. Everything else sucked.
peregrine 16y ago
My question is, just like in socket.io, why not fall back to flash audio when required?
- woogley 16y ago
  1) It's hard to detect when to fallback. You'd have to set up a list of user-agents you've tested and code around their individual issues. This is not ideal. 2) It doesn't solve the iOS problem (which, as this post points out, has even more issues than desktop browsers)
- tommoor 16y ago
  I was testing this last week with SoundManager2... the latency is far too great for games.
neovive 16y ago
Could applications such as PhoneGap be used to fill the void regarding audio on mobile devices? It's a shame that as the profits of app stores continue to rise, there is less motivation to promote and expand open standards.
- dpcan 16y ago
  I bought the ImpactJS engine, and I'm currently working on Android to run sounds through SoundPool while everything else happens in an embedded browser. Not much luck yet, but I think I can get there.
MatthewPhillips 16y ago
I coded a Chrome Web App and can sympathize. I eventually had to entirely recode my app because the first go was crashing the tab randomly when audio was playing. I can't imagine trying to do short sounds like in games.
slug 16y ago
Has anyone managed to make the audio tag work reliably with streaming? icecast server with ogg vorbis stream comes to mind. Tried konqueror (works), firefox 3.6 (doesn't work properly), chrome 9.x (doesn't work properly).
- cpearce 16y ago
  Can you file a bug with the appropriate browsers' bug trackers so they know about the problem?
  - _delirium 16y ago
    I believe this is the relevant Chrome bug: http://code.google.com/p/chromium/issues/detail?id=40344 http://code.google.com/p/chromium/issues/detail?id=40344
  - doublec 16y ago
    This is the Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=455165 https://bugzilla.mozilla.org/show_bug.cgi?id=455165 I know you know this, but for everyone else, Firefox doesn't play chained ogg files. Icecast uses this feature. If the icecast stream doesn't use chaining then it plays.
johnyzee 16y ago
How do you have <audio> working in the Android browser? Last I checked (2.2) the tag was supported but there was no format support (kind of like an airplane without wings). This was filed as a defect in June 2010 and a fix was promised, but not delivered for Android 2.2: http://code.google.com/p/android/issues/detail?id=9372 http://code.google.com/p/android/issues/detail?id=9372
tzs 16y ago
Ogg/Vorbis works just fine in Safari on my Macs. That's because Safari as far as I can tell is neutral when it comes to audio--it plays whatever you have Quicktime support for and I have installed Ogg/Vorbis.

109 points by sant0sk1 16y ago

Mobile Safari Can't pre-load sound files, only plays one sound at a time, severe lag, timing issues, clicks & pops, completely ignores every other call to play a sound, doesn't support Ogg/Vorbis. Utterly useless for anything. Oh, and did I mention it doesn't support Ogg/Vorbis?* More specifically Apple has crippled the Audio API by disabling the autoplay option, and disabling the JavaScript .play() function. This makes it completely impossible to build web games, or web apps that have any sort of audio feedback in Safari on any iOS device. Presumably they've done this to prevent web games from becoming popular and eventually dethrone the App store.

masklinn 16y ago
> Presumably they've done this to prevent web games from becoming popular and eventually dethrone the App store. No. They've done this to prevent web sites from outputting sound when they're loading (or just as they're done loading). Your blind hatred is moronic.
- trotsky 16y ago
  It seems obvious that Apple's interests don't coincide with fully functional cross platform mobile apps. Getting people to build with objective C and native code helps lock in and ensures that any sales go through their payment platform. If you don't think Apple has been moving in this way (anti-cross platform dev tools, requiring sales to use the iTunes payments) you simply haven't been paying honest attention.
  - e1ven 16y ago
    I understand that you're unhappy with Apple, but keep in mind that their original iPhone was HTML apps ONLY. Further, they continue run WebKit as an OSS project, and have worked to be accommodating to other mobile providers. The reason they dislike flash isn't some sort of inherent hatred, it's that it's outside their control. They can implement a HTML spec just as well as anyone else, and with Webkit, they can lead the way. Apple Wants to see a strong HTML web.
    - cookiecaper 16y ago
      >Apple Wants to see a strong HTML web. They want this as long as they are not the dominant platform. If MS and Apple swapped places tonight and Apple suddenly had 90%+ marketshare, it's likely that their strategies would flip just as fast, because it's the most profitable thing to do. Apple's interests are in ensuring that their platforms can run as much user-desired content as possible; they can do this by promoting cross-platform compatibility and interpreted code like JS and HTML. Microsoft has no need for this, since everything runs on Microsoft by default, because if it didn't, you'd miss out on 90%+ of your potential market. Instead, Microsoft's interests are opposite; they want to do everything they can to ensure that Windows is still required for any and all meaningful usage. This is the major point of IE; do enough to mostly work, but break compatibility where you can get away with it so that developers can't forget about Windows and IE. They also hope, though the environment isn't appropriate for this to work anymore, that IE will be your sole development platform and that considering the time it takes to make stuff work in IE, you will just leave things broken in all other browsers, further solidifying the MS lock-in. Lock-in is the holy grail for the software vendor. Apple is putting this in place as best as they can in the markets they control, and they are trying to ensure that MS doesn't lock them out of the desktop game, because they're still vulnerable believe it or not. MS is trying to ensure that Windows' death grip remains in place FOR. EVER., just as Apple wants iPhone/iPod to do the same.
      - masklinn 16y ago
        > Lock-in is the holy grail for the software vendor. Apple is not a software vendor.
        bane 16y ago
        http://store.apple.com/us/browse/home/shop_mac/software/apple?mco=MTM3ODExMzA http://store.apple.com/us/browse/home/shop_mac/software/appl...
        cookiecaper 16y ago
        They are a software vendor, and by vendor I mean producer. They don't not become a software vendor because they bundle the software and hardware together. They may make money on their hardware which is great for them, but it doesn't change the fact that OS X, iTunes, and the others, like all other software platforms, want lock-in; Apple merely wants to lock you in to the hardware too, so they use the software platforms to do that.
  - masklinn 16y ago
    > It seems obvious that Apple's interests don't coincide with fully functional cross platform mobile apps. No, it is not that obvious at all. May I remind you that Apple introduced the iOS SDK, spearheads what is usually recognized as the finest rendering engine out there and built what was the first mobile device actually able to surf the web? And that they have shown no will or wish to backtrack on any of these, doubling down instead? There is something much, much simpler to these issues: 1. Jobs's Apple will never again live and die at the whim of a third party. They suffered greatly during the Classic-OSX transition because Apple had lost control of the development platform itself (which was basically owned by Metrowerk and its CodeWarrior) 2. Jobs's Apple takes decisions it thinks benefit its customers and its customers are always its users. Now they may be wrong on that, and they may be misguided, but time and time again you can (pretty easily) explain the decisions of Jobs's Apple either as trying to avoid losing their platform to a third party or trying to make their user's experience life better. With web browser they fully control the platform. Hell, they control what can be argued the best web platform available (Google's Chrome is giving them a run for their money, in no small part by building upon their work). They don't fear people using their web browser, they wouldn't have built Canvas if they did (why not leave it out as SVG? Slow, hard to use and not a threat at all), they wouldn't be implementing WebGL, they wouldn't spearheads CSS animations and transitions and all the stuff that can make web applications snazzier and cleaner, they wouldn't have the engine with the best HTML5 support by far. Web stuff is not a threat, because they can have the best, shiniest and most advanced web stuff and they control all of it (number of full rendering engines allowed on iOS devices? one. Nobody else is allowed to ship a JS interpreter, therefore no full-blown web browser can avoid using the Webkit that ships with it and is fully built by Apple). Apple doesn't fundamentally mind or care for cross-platform mobile apps, what they fear is a third party's cross platform toolkit taking preeminence over their own tool and deciding of their platform's future. That is why they banned flash (also, because flash is a piece of shit). > Getting people to build with objective C and native code helps lock in That only works because you assert Apple wants to lock users in. > and ensures that any sales go through their payment platform. Cross-platform tools would have the exact same restriction or face bans. iTunes payment mandate is trivially explained through integration and user-experience (did you know that Apple's subscriptions services makes user information availability to magazines opt-in by the user, whereas just about every other service makes it opt-out if opt-able at all? That's because to Apple the device owner is the customer, to just about every other publisher the magazine is the customer). > If you don't think Apple has been moving in this way (anti-cross platform dev tools, requiring sales to use the iTunes payments) you simply haven't been paying honest attention. Either that, or I have not been wearing hate-shaped glasses. But really, I wonder why I bother with all that typing. I should know by now that HN's view of Apple is the same as /r/tech's: a bashing wankfest.
- dstein 16y ago
  No. They've done this to prevent web sites from outputting sound when they're loading (or just as they're done loading). The Audio API's .play() method is now always disabled. It was working on the iPad iOS 4.1 only through a hack, but Apple closed that hole in 4.2. I have no hatred of Apple, I own plenty of Apple products, but absurd strategic crippling of standards does not help my impression of them. It just wreaks of Microsoft-style embrace, extend, extinguish.
  - masklinn 16y ago
    > The Audio API's .play() method is now always disabled. Well… yeah, when would you want to enable it in order for the user to always have control over the sound?
    - dstein 16y ago
      I've made my point clear. If you think web browsers should not have the ability to play any audio that's a different topic than whether an OEM gets to pick and choose which parts of a standard to implement and which devices can support it. This is exactly what made the IE web development days so particularly maddening.
- ootachi 16y ago
  The author addresses that in the post: "I've heard some arguments that it is crippled on purpose, because you don't want a website to start blaring music at you as soon as you open it. Fine, I understand that argument. But why not ask the user for permission to play audio and then do it right? It's already been done with Geo Location and Storage."
  - deleted 16y ago
    [deleted]
LaGrange 16y ago
Ahahahaha no. Even if that's true, I, for one, despise the idea of any kind of audio autoplay for the web, be that flash or html5. If that breaks web games -- tough luck. I might be OK with some kind of whitelist, though -- same way it works e.g. for large off-line storage. But I like my games and audio editing software native anyway, thankyouverymuch.
- dstein 16y ago
  >If that breaks web games -- tough luck. It's worse than that, it breaks the standard. Audio API can no longer be used reliably if a major portion of the audience can't utilize it. Remember when days when one major heavyweight would refuse to follow standardized web protocols? You know, like how SVG was standardized in 2001 and 10 years later can still not be used reliably. Stuff like that needs to stop.
  - LaGrange 16y ago
    Well, if the standard allows autoplay without user consent then it's broken. Just because a standard is doesn't mean everyone should follow it. It should be followed when it's a good standard, and in this case it's arguable.
    - smackfu 16y ago
      So IE can not follow the parts of the standards they don't like, and that's cool with you now? It's a pretty silly position to take.
    - jdc 16y ago
      I imagine a user consent message in the form of Firefox's XPI "Allow/Deny" bar would work well for this.
  - yuhong 16y ago
    >You know, like how SVG was standardized in 2001 and 10 years later can still not be used reliably. And XHTML too.
newhouseb 16y ago
I think the official reason (I read somewhere in documentation) is because they don't want web sites to suck up mobile bandwidth by automatically streaming stuff. You can have videos autoplay, yes, but videos you can overlay with controls, whereas audio can be integrated into an interface in such a way that the user has no means to stop playback.

mambodog 16y ago

I hope for the day when the Webkit Web Audio API[1] or something like it is widely available so we can build rich audio apps like Audiotool[2] without relying on Flash. [1] http://chromium.googlecode.com/svn/trunk/samples/audio/index.html http://chromium.googlecode.com/svn/trunk/samples/audio/index... [2] http://audiotool.com/app http://audiotool.com/app [SWF]

mithaler 16y ago

Contrary to his claims, his test case seems to work mostly fine in Chrome 10.0.648.127 (beta) for me. I haven't tried the dev channel version though. Firefox doesn't appear to be working well at all, in either 3.6.16pre or 4.0b13 (but those are both unstable versions, so I'll withhold judgment). All of those were tested on Ubuntu. Regardless, he's definitely made his point well (and my setup showing different but similarly bad results from his only proves his point): support for the <audio> tag is not really as solved as browser manufacturers are claiming, and is not currently a suitable competitor to Flash. Direct link to test: http://www.phoboslab.org/files/html5audio/ http://www.phoboslab.org/files/html5audio/

gmac 16y ago

In summary: "there's some profanity ahead because HTML5 Audio is still that fucked up". My experience is entirely aligned. I was trying to use <audio> earlier this week for an incredibly simple task (occasionally play a 0.5s notification sound). The only thing that worked reliably was Chrome (9) with a data: URI. FF3.6 (or Chrome with a normal URI) would only play the sound once, and Safari wouldn't play it at all. (These are all the Mac versions, and I didn't test Opera).

transmit101 16y ago

A lot of discussion about the demise of Flash is focused on how CSS and JavaScript can now create equally pretty-looking websites, which is fair enough. But take it from a long-time audio developer: HTML5 audio is essentially useless for creating web applications involving almost any kind of audio. Even Firefox, which has the best HTML5 support so far, offers absolutely nothing like what is possible using the combination of a Flash client and a dedicated streaming server. Flash might have a lot of bad points (which I'd be the first to call out) but RTMP audio (which also handles both video and arbitrary data) really isn't its worst feature, and for this reason alone its going to be a significant part of the internet for many years to come.

Derbasti 16y ago
I totally agree that for video/audio players, Flash is a good technology (if hardware support is enabled and Flash is properly sandboxed). Flash is platform independant, needs no pre-installed codecs and can be easily blocked. None of this is true for any native audio/video tag.
aufreak3 16y ago
Not quite true. If you look at audio in HTML only through the lens of the <audio> tag, you're right. Some of the work-in-progress JS audio API stuff that doesn't depend on the audio tag rocks, even right now, in the dev builds. The future looks brighter than ever without Flash imo. http://chromium.googlecode.com/svn/trunk/samples/audio/index.html http://chromium.googlecode.com/svn/trunk/samples/audio/index... edit: The in-progress spec - http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html http://chromium.googlecode.com/svn/trunk/samples/audio/speci...

mckoss 16y ago

I don't give a shit anymore about this stupid piece of crap that Microsoft calls a Browser and throws out a release for every 3 years, just in time to not let it fade out completely but annoy web developers for more years to come. I can relate to this feeling.

asuth 16y ago

We've been using SoundManager 2 on quizlet.com for playing audio clips. We're not just playing long music clips in the background, so it's essential to have all the precise APIs for preloading, playing, and firing callbacks when sound is done playing. It handles all the browser deficiencies very elegantly, either with HTML5 or flash. Also, it's just 10k of js (gzipped) so it's pretty lightweight. link: http://www.schillmania.com/projects/soundmanager2/ http://www.schillmania.com/projects/soundmanager2/

JSig 16y ago
I'm using sound manager on http://hackernewsradio.com http://hackernewsradio.com as well. Right now I am just forcing flash. I had too many problems with html5 audio. I really wanted speex encoded audio but that is not an option. If I remember correctly Opera handled streaming speex/ogg like a champ. Firefox may have worked... I can't remember. Everything else sucked.

peregrine 16y ago

My question is, just like in socket.io, why not fall back to flash audio when required?

woogley 16y ago
1) It's hard to detect when to fallback. You'd have to set up a list of user-agents you've tested and code around their individual issues. This is not ideal. 2) It doesn't solve the iOS problem (which, as this post points out, has even more issues than desktop browsers)
tommoor 16y ago
I was testing this last week with SoundManager2... the latency is far too great for games.

neovive 16y ago

Could applications such as PhoneGap be used to fill the void regarding audio on mobile devices? It's a shame that as the profits of app stores continue to rise, there is less motivation to promote and expand open standards.

dpcan 16y ago
I bought the ImpactJS engine, and I'm currently working on Android to run sounds through SoundPool while everything else happens in an embedded browser. Not much luck yet, but I think I can get there.

MatthewPhillips 16y ago

I coded a Chrome Web App and can sympathize. I eventually had to entirely recode my app because the first go was crashing the tab randomly when audio was playing. I can't imagine trying to do short sounds like in games.

slug 16y ago

Has anyone managed to make the audio tag work reliably with streaming? icecast server with ogg vorbis stream comes to mind. Tried konqueror (works), firefox 3.6 (doesn't work properly), chrome 9.x (doesn't work properly).

cpearce 16y ago
Can you file a bug with the appropriate browsers' bug trackers so they know about the problem?
- _delirium 16y ago
  I believe this is the relevant Chrome bug: http://code.google.com/p/chromium/issues/detail?id=40344 http://code.google.com/p/chromium/issues/detail?id=40344
- doublec 16y ago
  This is the Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=455165 https://bugzilla.mozilla.org/show_bug.cgi?id=455165 I know you know this, but for everyone else, Firefox doesn't play chained ogg files. Icecast uses this feature. If the icecast stream doesn't use chaining then it plays.

johnyzee 16y ago

How do you have <audio> working in the Android browser? Last I checked (2.2) the tag was supported but there was no format support (kind of like an airplane without wings). This was filed as a defect in June 2010 and a fix was promised, but not delivered for Android 2.2: http://code.google.com/p/android/issues/detail?id=9372 http://code.google.com/p/android/issues/detail?id=9372

tzs 16y ago

Ogg/Vorbis works just fine in Safari on my Macs. That's because Safari as far as I can tell is neutral when it comes to audio--it plays whatever you have Quicktime support for and I have installed Ogg/Vorbis.