aeroheim

One thing that's really great about wasm is how it enables lots of native libraries to be usable in the browser. Recently I ran into performance issues due to limitations in the WebAudio API and was able to workaround it by compiling FFmpeg to wasm and using it instead. Being able to use FFmpeg in the browser is very powerful and brings a huge suite of encoding/decoding capabilities that browsers currently lack right now (at least until WebCodecs becomes standardized and implemented).

On another side, compiling existing C/C++ libraries to wasm is still very painful. I struggled a lot using Emscripten to port FFmpeg to wasm - you have to compile EVERY dependency to wasm (so I ended up re-compiling libopus, libmp3lame, etc.) and the compiler warnings are often super cryptic which made the entire process a complete nightmare. The process really needs a lot of work still.

For anyone that's interested, this is the result from my endeavor: https://github.com/aeroheim/audio-file-decoder

And also check out a great general purpose FFmpeg wasm port here: https://github.com/Kagami/ffmpeg.js

hi HN!

I've been working in the browser audio domain recently and noticed to my surprise that WebAudio has no way to decode audio files efficiently. WebAudio has no support for partial decoding and can only decode entire audio files upfront which results in huge CPU and memory usage.

For example, decoding a typical stereo 44.1 KHz 1-hour long audio file (e.g a podcast) into uncompressed floating point samples would consume (3600s * 44100Hz * 4 bytes * 2 channels) = ~1.27 GB of memory. Nice

Obviously this isn't acceptable so I ended up creating this library to work around this issue. I ported FFmpeg over to WASM using Emscripten (a painful process) and then implemented an audio decoder with support for partial decoding. I hope this library can help anyone else with the same issue or at least serve as an additional reference for those looking to roll their own WASM-based workarounds.

Thanks for taking a look!

P.S: extra info/ranting about WebAudio below for those interested

Others have already pointed out this glaring issue in the WebAudio API: https://github.com/WebAudio/web-audio-api/issues/1305

But it's sad to see that so many libraries/applications out there still rely on it such as: https://github.com/bbc/waveform-data.js https://github.com/katspaugh/wavesurfer.js

Thankfully this issue should hopefully be addressed whenever WebCodecs is standardized and implemented: https://github.com/WICG/web-codecs/issues/28

But until then it's quite disappointing that developers have to go as far as rolling their own WASM-based solution just to work around the WebAudio API. I've heard unpleasant things about WebAudio and came in with zero expectations and yet was still disappointed. ¯\_(ツ)_/¯

MDN has such a large impact and influence on the web development community so it's baffling to me as to why this decision was made. I just hope there are plans in the work to at least preserve if not continue its operation eventually under a different organization perhaps.

Honestly, I just really don't want to think of the alternatives without MDN. I don't think ANYONE wants to go back to w3schools.

Hey HN!

I wanted to share a library that I’ve been working on for a few months now called midori. This library was built with three.js and uses WebGL. It allows users to use their own images as animated backgrounds for their websites.

The primary features supported by the library are:

  - Configurable camera
  - Animated transitions between backgrounds
  - Post-processing effects & particles

Implementation-wise, there's a lot of interesting stuff accomplished via camera manipulation, shaders, and tweening.

I would appreciate any feedback. Thanks for taking a look, it means a lot!