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.
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,
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 ? :(
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.
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