Missing standalone .wasm artifact in browser example build (WASM always embedded in JS)

[jaiswal-naman]

Description:
When building the examples/whisper.wasm (formerly examples/stream.wasm) target with Emscripten, no separate .wasm binary is emitted. Instead, the bytecode is Base64-embedded inside the generated JavaScript “glue” (e.g. stream.js), so there is no stream.wasm (or whisper.wasm) to copy into a web server’s public/ folder. This breaks the documented integration flow for browser apps (Next.js, React, etc.) that assume standalone WASM + JS helpers.

Steps to reproduce:

Clone the repo (e.g. v1.7.4 or latest main).

Install and activate Emscripten SDK.

From whisper.cpp root:

bash
mkdir build-wasm && cd build-wasm
emcmake cmake ../examples/whisper.wasm
cmake --build . --parallel
Inspect build-wasm/bin/whisper.wasm/ (or build-wasm/bin/stream.wasm/). You will find only:

stream.js (with embedded WASM)

helpers.js

(no .wasm file)

Expected behavior:

The build should produce three separate files:

stream.wasm (WebAssembly binary)

stream.js (loader/stub)

helpers.js (auxiliary code)

These can then be copied directly into a web app’s public/ directory for browser loading.

Actual behavior:

Only JavaScript files are emitted; the WASM module is inlined.

No standalone .wasm exists unless the user explicitly rebuilds with -s SINGLE_FILE=0, which is not documented in examples/whisper.wasm/README.md.

Environment:

whisper.cpp commit/tag: v1.7.4 (or latest main)

Emscripten SDK: 3.1.58 (emsdk up to date, activated)

OS: Windows 10 (PowerShell 5.1) / Linux / macOS (N/A)

CMake: 3.21+

Build commands: as above

Suggested fix:

Update examples/whisper.wasm/README.md to explicitly document how to disable single-file embedding (-s SINGLE_FILE=0).

Modify the CMake target in examples/whisper.wasm/CMakeLists.txt to set EMSCRIPTEN_LINK_FLAGS:STRING=-s SINGLE_FILE=0 by default, producing separate .wasm.

Add an example step or small script that copies stream.wasm, stream.js and helpers.js into a web server folder.

This will restore the standalone WASM workflow assumed by downstream projects (e.g., Next.js) and simplify browser integration for new users.