Uncaught Error: Converting base64 string to bytes failed.

[wxfred]

Please include the following in your bug report:

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.46 (1960782)
clang version 18.0.0 (https://github.com/llvm/llvm-project 75501f53624de92aafce2f1da698b249a7293dc7)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: C:\emsdk1\upstream\bin

I downloaded the entire emscripten project from github on 2023/9/28, the compiled xxx.wasmmodule.js by this new version came out a problem after being loaded: Uncaught Error: Converting base64 string to bytes failed.

I locate the problem and compare it with the emscripten I downloaded on 2022, in xxx.wasmmodule.js, the 2023 version is

// include: base64Utils.js
// Converts a string of base64 into a byte array.
// Throws error on invalid input.
function intArrayFromBase64(s) {

  try {
    var decoded = atob(s);
    var bytes = new Uint8Array(decoded.length);
    for (var i = 0 ; i < decoded.length ; ++i) {
      bytes[i] = decoded.charCodeAt(i);
    }
    return bytes;
  } catch (_) {
    throw new Error('Converting base64 string to bytes failed.');
  }
}

the 2022 version (which is no error) is

// Converts a string of base64 into a byte array.
// Throws error on invalid input.
function intArrayFromBase64(s) {

  try {
    var decoded = decodeBase64(s);
    var bytes = new Uint8Array(decoded.length);
    for (var i = 0 ; i < decoded.length ; ++i) {
      bytes[i] = decoded.charCodeAt(i);
    }
    return bytes;
  } catch (_) {
    throw new Error('Converting base64 string to bytes failed.');
  }
}

and emcc -v of the 2022 version is

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.7 (48a16209b1a0de5efd8112ce6430415730008d18)
clang version 15.0.0 (https://github.com/llvm/llvm-project fbce4a78035c32792b0a13cf1f169048b822c06b)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: C:\emsdk\upstream\bin

the compile command is like

emcc -lembind `
    source/xxx  `
    -o dist/xxx.wasmmodule.js `
    -I xxx `
    -O1 `
    -s TOTAL_MEMORY=128MB `
    -s SINGLE_FILE=1 `
    -s BINARYEN_ASYNC_COMPILATION=0 `
    -s ENVIRONMENT=web `
    -s EXPORT_NAME=xxx `
    -Wno-c++11-narrowing -Wno-implicit-function-declaration `
    --post-js thirdparty/em-es6-module.js

[rbdannenberg]

I encountered the same problem with the same emcc 3.1.46. As a reality check, I tried the example here: https://github.com/GoogleChromeLabs/web-audio-samples/tree/gh-pages/audio-worklet/design-pattern/wasm-supersaw. One way to do this is:

• download the whole repo.
• cd to the gh-pages directory.
• Serve that tree with python3 -m http.server 8000, and
• visit http://localhost:8000/audio-worklet/design-pattern/wasm-supersaw

This example works, but if you use the corresponding Makefile in https://github.com/GoogleChromeLabs/web-audio-samples/tree/main/src/audio-worklet/design-pattern/wasm-supersaw to make a new synth.wasm.js and replace the existing one, the example no longer runs, and the error is the same "Converting base64 string to bytes failed" error.

To explore further, since there is a working synth.wasm.js in the repo, I took out the existing code to define atob() and in intArrayFrameBase64(s), I called decodeBase64() instead of atob(). I also added var decodeBase64 = typeof atob == 'function' ? atob : function (input) { ... } at the top of the file using the implementation from the repo version of synth.wasm.js. This seems to solve the immediate problem of decoding base 64.

However, execution proceeds and I now get the error:

Uncaught TypeError: this._module._malloc is not a function
    at HeapAudioBuffer._allocateHeap (wasm-audio-helper.js:67:34)
    at new HeapAudioBuffer (wasm-audio-helper.js:54:10)
    at new SynthProcessor (synth-processor.js:19:28)

and I see that _malloc is defined differently in the 2023 emscripten-generated synth.wasm.js than in the 2022 version, and many definitions follow the same pattern.

Is there any example with source code that builds a working audio worklet using wasm? I guess I can revert to emcc 3.1.11 which worked for me in May 2022.

[sbc100]

It looks like your issue with HeapAudioBuffer._allocateHeap is that malloc is not being exported. It looks like you need to add _malloc to the -sEXPORTED_FUNCTIONS=... list.

[sbc100]

@wxfred, can you set a breakpoint on the error to see what the root cause was? Is it that atob() is not available? If so, what platform are you running on?

[rbdannenberg]

I'm using (recent) Google Chrome Version 117.0.5938.132 (Official Build) (arm64). Not sure what ECMAScript this implies.
Still working with wasm-supersaw example described above and emcc 3.1.46, the compiled synth.wasm.js tries to call atob(s) in intArrayFromBase(s) and throws an error because atob(s) is undefined at the point that intArrayFromBase(s) is called.

I found that atob is conditionally defined in synth.wasm.js just above intArrayFromBase in synth.wasm.js, but since the definition (or I guess more properly the binding of symbol atob) takes place in a top-level statement, hoisting does not ensure that things are defined properly.

When I manually moved the atob code near the top of synth.wasm.js (just after the "var Module = ..." declaration, but probably doesn't matter), the wasm-supersaw example runs.

Why is atob not defined? Near the end of the generated synth.wasm.js, it says:

// include: postamble.js
// === Auto-generated postamble setup entry stuff ===

followed by a conditionally binding of atob, which in simplified form looks like:

if (typeof atob == 'undefined') {
  if (typeof global != 'undefined' && typeof globalThis == 'undefined') {
    globalThis = global;
  }
  globalThis.atob = function(input) { ... }
}

Since moving this to the top of the file makes things work, it seems clear that it is defined too late.

In fact, looking at the call stack when the error occurs, the computation seems to be initiated by the declaration:

var wasmExports = createWasm();

which occurs before the definition of atob(). This explains why atob() is undefined.

Reverting to an earlier emscripten seems to require an earlier version of Python3 and I gave up on making it work.

The bottom line is I see no way to use emcc 3.1.46 for audio worklets. Can this be?

[sbc100]

Ah, you are trying build and audio worklet. That makes sense why atob would be missing then. I was looking for -sAUDIO_WORKLET in your settings but I didn't see it.

I guess we need fix the https://github.com/GoogleChromeLabs/web-audio-samples to use that option since you are not the first person to try to build without -sAUDIO_WORKLET. See #19845 (comment).

[rbdannenberg]

When I added -sAUDIO_WORKLET emcc said to remove -sSINGLE_FILE and add -sWASM_WORKERS (I modified -sWASM to `-sWASM_WORKERS). So now there are 3 files produced: synth.wasm.js, synth.wasm.aw.js and synth.wasm.ww.js. The old code doesn't run, I assume because didn't do anything with the synth.wasm.aw.js and synth.wasm.ww.js. I'll point GoogleChromeLabs to this conversation. There's so much choreography involved in loading, initializing and communicating with an audio worklet, it would really help to have a working example. When the AUDIO_WORKLET option was created, was there any simple test, and is it available and working now? Thanks for all the pointers to far.

[sbc100]

The -sAUDIO_WORKLET setting is documented here: https://emscripten.org/docs/api_reference/wasm_audio_worklets.html

There are some tests for it here: https://github.com/emscripten-core/emscripten/tree/main/test/webaudio

[rbdannenberg]

I was off for a week but spent today trying to make a wasm audio worklet. I looked at test/webaudio but I couldn't find any information about it or how to run it. I was able to use instructions in #20410 to compile it, and it generates a test.htm file, but it doesn't work because

Uncaught ReferenceError: SharedArrayBuffer is not defined
    <anonymous> http://localhost:8080/test.js:382

Eventually I found "test/runner interactive" to run the test and it actually runs, but things are so wrapped up inside a test framework, that it's very hard to understand. Even the source code is huge and automatically generated. I'm still looking for any example of a web audio wasm program.

[ad8e]

SharedArrayBuffer is not defined

Make sure you're setting the CORS headers in your local web server. python3 -m http.server 8000 won't cut it.

[rbdannenberg]

I think I'm setting CORS headers correctly. At the point where the error occurs, windows.isSecureContext is true (see Feature Detection in https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts, referenced by https://developer.mozilla.org/en-US/docs/Web/API/AudioWorklet), although I'm not certain that's a correct or sufficient test.