-
Notifications
You must be signed in to change notification settings - Fork 135
Description
Looking at at the wavelib:gh-pages
branch, I see that it loads a script called wavelib.js
, which was apparently produced by Emscripten, but it's not really a wasm, but rather that "js asm" dialect. I've tried to fix it by producing a proper wasm binary from the src/*.c
sources, but only found out that the demo uses a mysterious function cwave_transform
that's not defined in any of those C sources. I've tried searching the entire github for it with no success. I guess that wavelib.js
is a really old build of some C lib that's changed since then.
If you replace that wavelib.js
with real wasm, the demo will be a lot faster (like 10x faster). Here's a bash script to produce wasm files:
OUTPUT_FILE="./js/wavelib.js";
INPUT_FILES="./src/*.c";
echo "Building wasm from $INPUT_FILES to $OUTPUT_FILE";
emcc $INPUT_FILES -O3 \
-s WASM=1 \
-s EXTRA_EXPORTED_RUNTIME_METHODS='["cwrap"]' \
-s EXPORTED_FUNCTIONS="['_malloc','_free', 'cwave_transform']" \
-s ALLOW_MEMORY_GROWTH=1 \
-s FILESYSTEM=0 \
-o "$OUTPUT_FILE";
The rest of the logic remain the same: index.html still loads wavelib.js, which behind the scenes, loads wavelib.wasm, and all calls to Module._cwave_transform
and the like will be transparently routed to the wasm binary.