Breakthroughs In HTML Audio Via Manipulation With JavaScript 141
jamienk writes "Imagine if you could grab and manipulate audio with JavaScript just like you can images with Canvas. Firefox experimental builds let you do just that: crazy audio visualizations, a graphic equalizer, even text-to-speech, all in JavaScript! Work in progress; you need a special build of Firefox (videos available), being worked on via W3C."
don't say you weren't warned: (Score:2, Interesting)
the future os is the browser
the future os programming language is javascript
enjoy!
Flash Helper; State of JS Audio (Score:3, Interesting)
From what I've read, there was an off-screen flash helper playing the audio, and I'm not surprised. It's nigh impossible to get reliable audio with JavaScript only. People have been doing some experiments with stuffing data urls into , , and tags for a while now (heck, I've been doing it since last fall) in order to programmatically generate audio, but it generally suffers from performance issues and various glitches for a while now. You can mostly pull it off only if you stick with MIDI or you use Flash or Java to deliver the audio.
Here's something I didn't get until recently: Audio is in some ways harder than video. It's more timing sensitive. With video, you're generally slinging a lot more data per frame, but you can get away with *much* lower frame rates... 24 fps works, 60's not bad, and you don't have to get much higher than that to pass the threshold of perception. With audio, very small "frames"/samples will hold adequately resolved data from one point in the signal, but you have to move a lot *more* of them (44,100 of 'em per second for CD quality audio) and move them *reliably* in order to get sound fidelity. JavaScript timing might be millisecond reliable except in IE, but it's not microsecond reliable. Totally realtime programmatic sound is probably out of the question for a while.
But, programmatic generation of the audio *data* is possible now, and you can probably precompute enough things ahead of time that if they can work the bugs out of the audio tag or something else to enable microsecond level starting/stoping/looping of playback, then pure JavaScript audio would get real wings.
Re:I'm all for this (Score:3, Interesting)
Apple picked PNG because Microsoft didn't. And screencap image formats were hardly going to be an industry deal breaker. BMP files are so obvious as to really not give any leverage to Microsoft. Any patent on the silly thing would be overturned("Method for displaying a picture by lining up the colored pixels in order?").
Apple is pro-open-formats only if there's no way to get a lock-in. Apple is a patent holder with MPEG-LA, hence their preference for H.264.
Remember that there's nothing preventing you from installing Theora and Matroska codecs on your Windows box, same as with your Mac. Sure, media player will push you towards wma, but Apple will push you towards Apple Lossless.
"Microsoft has a history of always creating their own formats even when a multitude of alternatives already exist"
- iPad USB dongle
- iPhone/Pod connector
- Their old practice(no longer the case) of locking their RAM so only their RAM would work on their hardware
- The stupid one button mouse(yes, it's no longer the case, but it was).
Not saying MS is good. They're not. But neither of them are. Trying to say "At least Apple..." these days is a tricky game.
Also, MS has stated that IE8+ will handle WebM just fine as it can be installed via Media Player. Opera stated support. Mozilla breathed a sigh of relief and quickly said the same. Apple(or at least Turtleneck Prime) is the only one that seemingly indicated they wouldn't support it by throwing some lawsuit FUD around. They may yet, but the response wasn't exactly positive.