6 ms·

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 aud

by mise 15y ago

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?

nddrylliog 15y ago
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?
- seanalltogether 15y ago
  At 50% cpu utilization this is very impractical outside tech demos.
  - jensnockert 15y ago
    Yes, please help optimize it.
    - seanalltogether 15y ago
      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.
      - jensnockert 15y ago
        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.
        nddrylliog 15y ago
        Switching entirely from Strings to typed arrays would help a great deal imho. Right now the code is hybrid.
  - deleted 15y ago
    [deleted]
- keeperofdakeys 15y ago
  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).
  - nddrylliog 15y ago
    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!
    - quinnirill 15y ago
      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.

by mise 15y ago

nddrylliog 15y ago

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?

seanalltogether 15y ago
At 50% cpu utilization this is very impractical outside tech demos.
- jensnockert 15y ago
  Yes, please help optimize it.
  - seanalltogether 15y ago
    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.
    - jensnockert 15y ago
      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.
      - nddrylliog 15y ago
        Switching entirely from Strings to typed arrays would help a great deal imho. Right now the code is hybrid.
- deleted 15y ago
  [deleted]
keeperofdakeys 15y ago
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).
- nddrylliog 15y ago
  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!
  - quinnirill 15y ago
    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.