Hacker News Reader

Comment by mise | Hacker News Reader

Awesome! But...

I'm not a JS guy. I can't contextualise this. How does this compare to HTML5 browser-based audio playing? Will this be a new way to make an audio button? Or does it go much deeper than that for JS apps?

View on HN

From what I hear,the HTML5 <audio> tag implementation quality varies wildly. It hasn't been used much in production for desktop-targeted web apps. It is, however, quite popular on the iPlatforms, because you have no Flash there!

As far as I can tell, jsmad is not going to replace the HTML5 audio tag on mobile devices. However, it does constitute a nice legal workaround for MP3 in desktop browsers such as Firefox.

It gives access to the full decoded audio data, the code doing the playback (player.js) is actually just a tiny little part of jsmad! The HTML5 audio tag seems to also give access to the decoded data, but I haven't messed with it enough to know what's the level of control.

What would be really interesting though, would be something like streaming audio applications - completely flash-free, something that would be (imho) hard to achieve using the HTML5 <audio> tag.

My opinion is that it's wrong to try to add everything as browser built-ins. If the Javascript are powerful enough, why not use it to decode PDF/MP3/whatever? I'm guessing we won't see a video decoder for a few months more, but who knows? Things are moving fast.

So to answer your original question: it goes much deeper. For an audio button it would probably be overkill, but then again, why not?

At 50% cpu utilization this is very impractical outside tech demos.

Yes, please help optimize it.

The question is can it be optimized? My knowledge of this stuff is very limited but I assume javascript object wrappers for number types and lack of SSE/SSE2 instructions will be the biggest blockers to performance.

I doubt SSE2 would help much, at most 2x on arithmetic performance. Much time is spent fiddling with arrays, and the newer version of firefox the better that performance is. In addition there are many optimizations to do.

A Pentium 1 can decode MP3s in assembly, so in Javascript we probably need a few times more power, but not insanely much more.

Switching entirely from Strings to typed arrays would help a great deal imho. Right now the code is hybrid.

One of the main problems with the html5 audio tag isn't that it doesn't play audio, it is that it doesn't allow the control needed for things like gaming (playing different streams in different speakers, no latency guarantees, etc).

This is exactly where jsmad could shine, even on current browsers (on FF4/Chrome10+). Game usually use small sound effects, that can be decoded in a few ms and then stored in buffers. From there, it'd be very easy to do the mixing in pure JS using audiolib.js - which is a treat, btw! You'd get as many audio channels as your CPU can handle, mixed in realtime. If the Audio Data API / Web Audio API support more than 2 channels, we might even be looking at full 5.1 demos real soon.

This is so exciting!

I agree! And actually you can already do multichannel stuff, but currently that requires you to use either Audio API exclusively, because Chrome supports only 2 channels for javascript processing (but the internal effects are multi-channel), but Firefox supports only javascript processing.

Reply on news.ycombinator.com