19 comments

[ 4.8 ms ] story [ 54.8 ms ] thread
Those of us who were around in the bad old days of midi files played from web pages might consider difficulty in playing sounds to be a Good Thing.
But then there are those of us who have tried emulating drum machines with HTML and Javascript - for example, http://bitrotten.com/dr110 - and find the abysmal implementation of audio in browsers to be frustrating, particularly with all the naive talk about how HTML5 will make Flash obsolete, or how you should just make a web app if you want iPhone users without going through the iTunes store.
Give me easy audio but no autoplay and I will be happy. The same applies for video. In fact, in unicorn-land I would like it also for heavy animations. At least one advantage with flash is Flashblock ;-)
Without autoplay you cannot build a web based app that has audible dings for things like alerts or any sort of JavaScript music player or game. I'm okay with a web browser having the option of disabling audio though.
No problem : play and further autoplay could be authorized on a per app basis.
Collaborative DAW and mixing applications need to exist soon. There is a lot of really cool stuff that could be done in this space. Opportunities are endless and both at the professional and casual consumer level markets of happily paying users exist.
There is probably a good reason this is so difficult: web sites that play sounds other than in the context of audio or video media are very often quite annoying, and thus there hasn't been much demand.
Or myspace. I wish the person who made the "autoplay my music whenever someone visits my page" setting would get shot.
(comment deleted)
I use soundmanager2 for a large project I'm currently working on, although it has it's... foibles, it does not actually require flash in most instances as of latest release, it can also use HTML5 audio where available. And the size of the library is relevant in terms of the work that has already been done for you, though of course one of the aforementioned foibles is that it's a touch hard to follow and you could fairly say the size contributes to that.

Personally I think lots of one letter variable names and liberal prefixing of everything with _ is a bigger annoyance, but to each their own I guess.

Why no mention of jplayer.org? 37kb minified, flash fallback, works great (http://mixest.com).

Maybe because he's not trying to play music.

Generating sounds is rather straightforward with HTML5. On the other hand, manipulating sound bytes (which would enable both synthesizer-like web apps and audio streaming) really ain't that easy to do.
Chrome

Has broad support and will play most stuff thrown at it. Also, no cross-platform differences.

Thank you Chrome.

I've found the claim that Chrome "will play most stuff thrown at it" to be a false one. Here's a Chrome bug I discovered last month while hacking a Flask application:

  mkdir static && wget http://www.soundjay.com/button/beep-1.mp3 -O static/beep.mp3 && python -c "import flask; flask.Flask(__name__).run()"
Then hit: http://127.0.0.1:5000/static/beep.mp3

The mp3 plays fine in Firefox (not natively of course), but doesn't play at all in Chrome. The same problem extends to the HTML5 audio tag (eg. <audio src="static/beep.mp3" />).

Works perfectly here. Not a real nice test tone though, heh.
There was also img dynsrc for video in IE, BTW.
The proposed solution uses JS to check what formats the browser reports support for, in order to tailor the <audio>'s src attribute:

    if(!!(a.canPlayType && 
          a.canPlayType('audio/ogg; codecs="vorbis"')
         .replace(/no/, '')))
      a.src = "/sounds/ping.ogg";
    else if ...
Does anyone know if this is more successful than the standard HTML5 way, which is to include in the <audio> element multiple <source> elements pointing to different formats?
I needed to make play sound in a browser today, and luckily remembered this story. You have saved me a day of raging around the internet trying to get sound to play in browser x.