Howler.js - Lightweight Javascript library for Web Audio and HTML5 Audio(goldfirestudios.com)
goldfirestudios.com
Howler.js - Lightweight Javascript library for Web Audio and HTML5 Audio
http://goldfirestudios.com/blog/104/howler.js-Modern-Web-Audio-Javascript-Library
8 comments
This is kind of an aside, but I have a question. Is the format of the W3C specification an actual value-add to ideas like this? I mean, if I look at http://www.w3.org/TR/webaudio/ my eyes kind of glaze over, whereas if I read something like http://json.org/ (to pick something at random) it is far more accessible. Heck, most of the RFCs I've read are more readable than the W3C formatted specs (and are often written in a human, witty way).
what's the advantage of using the web audio api for this over html5 audio elements? i don't think there's anything here that html5 audio elements can't do...
HTML5 audio is missing many basic features! Like panning. If you make a game, HTML5 audio does not cut it. The Web Audio API is amazing in comparison, with full support for audio routing graphs with processing nodes, filters etc. set up how you want for a maximum efficiently low-memory low-latency audio system. HTML5 audio is like a big tape player that you can press "play", "pause", "stop" and if you're lucky maybe slow it down or speed it up and that's it. They're worlds apart.
yes, but the OP doesn't actually expose any of the functionality you list as exclusive to web audio. which is why i asked my question.
The best analogy I've seen is this:
html5 audio : web audio api :: html image : html5 canvas
html5 audio : web audio api :: html image : html5 canvas
...except no browser fully supports web audio and basically all browsers fully support canvas.
http://caniuse.com/audio-api (no-one except partial Chrome) http://caniuse.com/#feat=audio (everyone except early Android)
http://caniuse.com/audio-api (no-one except partial Chrome) http://caniuse.com/#feat=audio (everyone except early Android)
For starters, Web Audio is much more performant than HTML5 audio.
This seems to be true, but I never understood why. HTML5 Audio is the simpler API; browsers vendors should be able to optimize it much more, yet, it still performs as bad as it did 2 years ago[1].
Another interesting fact is that iOS supports WebAudio, but doesn't support HTML5 Audio (for a meaningful definition of "support"). I just don't get it.
[1] http://phoboslab.org/log/2011/03/the-state-of-html5-audio
Another interesting fact is that iOS supports WebAudio, but doesn't support HTML5 Audio (for a meaningful definition of "support"). I just don't get it.
[1] http://phoboslab.org/log/2011/03/the-state-of-html5-audio
Yup, that's totally correct and sadly not much has changed since that blogpost. I still have several bugs filed on HTML5 Audio on chrome that have received no attention, that cause problems in BananaBread,
https://developer.mozilla.org/en-US/demos/detail/bananabread
I suppose their assumption is that everyone should use Web Audio and forget about HTML5 Audio? It's sad though because Web Audio is total overkill for many things.
https://developer.mozilla.org/en-US/demos/detail/bananabread
I suppose their assumption is that everyone should use Web Audio and forget about HTML5 Audio? It's sad though because Web Audio is total overkill for many things.
I didn't have played with WebAudio yet, but I assume that the main problem of HTML5 <audio/> is that the controls cannot be customized to fit the stylesheet. Using WebAudio probably allows to use custom html structure.
So the main question is : when will we have a standard shadow dom styling ? :(
So the main question is : when will we have a standard shadow dom styling ? :(
You can do any customization with <audio/> that you can with Web Audio. The element doesn't have to be in the DOM to play audio.
It's actually harder to provide custom UI for the Web Audio API since seeking and general stream navigation are a complete afterthought and their API makes them a pain.
It's actually harder to provide custom UI for the Web Audio API since seeking and general stream navigation are a complete afterthought and their API makes them a pain.
interesting. i haven't messed around with web audio in about a year and wasn't aware that this was now the case. my googling failed to turn anything up so i'd be interested in reading anything you might be able to link me to about this.
also, since you say "for starters" i'm curious what your other reasons are.
also, since you say "for starters" i'm curious what your other reasons are.
Are there any decent free tools for doing batch conversions on mp3 or wav files to the formats needed for HTML5 audio across browsers?
Has Firefox implemented Web Audio by now?
Unfortunately, no. However, it will have at least partial support in Firefox 20, so it is on its way.
Doesn't work on iphone5 either.
Check your mute switch. I have an iPhone 5 and all of the functions work.
Thanks... That fixed it. However maybe you should detect if the mute switch is on and display a message. I'm guessing a lot of others would not think of that.
> Thanks... That fixed it. However maybe you should detect if the mute switch is on and display a message. I'm guessing a lot of others would not think of that.
Sure, except there is not an API call for that.
Sure, except there is not an API call for that.
Nice work though