Any plans to support WASM / Browser?

[sandreas]

Hello,

first of all: Thanks for this great library.

Today I tried to use it with Linux and it worked flawlessly. Unfortunately when using an AvaloniaUI Cross Platform GUI Application and trying to start the WASM / Browser build, there is an error:

Unsupported Operating System: Browser

Since this is a wrapper for miniaudio and miniaudio seems to support WASM builds, I would like to ask, if you plan to integrate support for WASM or if I missed something

miniaudio works on all the major desktop and mobile platforms, including Windows, macOS, Linux, BSD, iOS, Android and Web (via Emscripten).

Examples:

• C# Project: https://github.com/sandreas/eduart
  • Relevant Code: https://github.com/sandreas/eduart/blob/f8ca5e8c9cb65066c03ddb1d32a2ab84cb935c69/eduart/ViewModels/HomeViewModel.cs#L55
• Short 1s Audio: animal-voice.zip
• Online Base64 Converter: https://base64.guru/converter/encode/file

I basically ran all this using the AvaloniaUI xplat example and the SoundFlow example from the readme using a MemoryStream to rule out local file accessing errors:

using var audioEngine = new MiniAudioEngine(44100, Capability.Playback);

// 
var audioBytes = Convert.FromBase64(".....");
var audioStream = new MemoryStream(audioBytes);

// Create a SoundPlayer and load an audio file
var player = new SoundPlayer(new StreamDataProvider(audioStream));

// Add the player to the master mixer
Mixer.Master.AddComponent(player);

// Start playback
player.Play();

[LSXPrime]

In theory, support should be available. The reason it wasn't supported at launch is due to a misunderstanding on my part, as I initially misread "Emscripten" as "ECMAScript" when I saw it alongside HTML5, likely due to my declining eyesight. I'll add it to my TODO list, and it should be implemented in the next few commits.

[sandreas]

I'll add it to my TODO list, and it should be implemented in the next few commits.

Cool, thank you. Let me know if you need help or testing.

BTW: I found this article, I don't know if this is helpful, if not, just ignore it :-)

[E-Hain]

In theory, support should be available. The reason it wasn't supported at launch is due to a misunderstanding on my part, as I initially misread "Emscripten" as "ECMAScript" when I saw it alongside HTML5, likely due to my declining eyesight. I'll add it to my TODO list, and it should be implemented in the next few commits.

I would love if you added WASM support!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed if no further activity occurs.

If this issue is still relevant, please leave a comment indicating that you would like it to remain open.
Thank you for your contributions.

[sandreas]

+1
This should not be auto-stale :-)

[vchelaru]

I'm also interested in using this in the FlatRedBall engine that I maintain. I have been very frustrated with NAudio's lack of updates and similar lack of platforms. If I could get this to work on WASM then this could be the audio solution we use at FRB.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed if no further activity occurs.

If this issue is still relevant, please leave a comment indicating that you would like it to remain open.
Thank you for your contributions.

[LSXPrime]

This shouldn't be marked as stale.

The WASM support was actually the most problematic issue I worked on, mainly because the JSInterop lacks complex marshalling. And while I have finally tackled that and got compilation done, for some reason, the JSImport attribute and JSHost can't seem to find the exported functions even though I can call them from the browser console.

I will get busy for the next two weeks, so this will be delayed, sorry.

[sandreas]

@LSXPrime

I will get busy for the next two weeks, so this will be delayed, sorry.

If you need help with the JSHost / JSImport stuff, feel free to reach out. While I'm not an expert, I would recommend to (if possible) NOT use JSHost at all and use globalThis instead.

globalThis refers to window and you can translate objects and functions without using any of JSHost- so [JSImport("globalThis.localStorage.getItem")] refers to window.localStorage.getItem, which basically means that you can map global functions without JSHost.

See https://github.com/sandreas/Avalonia.SimplePreferences/blob/335879bb0554a444ef218da53d03f1d17e212829/Avalonia.SimplePreferences/Storages/BrowserStorage.cs#L61 for an example.

However, since miniaudio WASM probably will spit out a js file which needs to be loaded, you could refer to a more elaborate explanation how to use JSHost, which is burried in the AvaloniaUI discussions containing my notes on how to do it:
AvaloniaUI/Avalonia#18139 (reply in thread)

Hope it helps. Good luck!

[LSXPrime]

Any help would be appreciated. I uploaded my last changes regarding the WASM support to branch wasm-platform. Currently, it loads, but on calling methods like AllocateContext from C# code, which returns a pointer nint/IntPtr, I got this error in the browser console.

MONO_WASM: Exception marshalling result of JS promise to CS:  RuntimeError: memory access out of bounds
    at mono_class_get_image (dotnet.native.wasm:0x68dd07)
    at get_native_to_interp (dotnet.native.wasm:0x8d7ea4)
    at mono_wasm_get_native_to_interp_trampoline (dotnet.native.wasm:0x754c60)
    at interp_create_method_pointer (dotnet.native.wasm:0x62d363)
    at jit_compile_method_with_opt_cb (dotnet.native.wasm:0x73f143)
    at mono_llvm_cpp_catch_exception (dotnet.native.wasm:0x65175e)
    at jit_compile_method_with_opt (dotnet.native.wasm:0x73f053)
    at mono_jit_compile_method (dotnet.native.wasm:0x73ee76)
    at mono_compile_method_checked (dotnet.native.wasm:0x7056e7)
    at mono_delegate_to_ftnptr_impl (dotnet.native.wasm:0x6e8f0f)

pt @ logging.ts:26
(anonymous) @ marshal-to-cs.ts:339
Promise.then
mo @ marshal-to-cs.ts:329
(anonymous) @ marshal-to-cs.ts:83
(anonymous) @ invoke-js.ts:202
Ll @ invoke-js.ts:276
$do_icall @ dotnet.native.wasm:0x631112
$do_icall_wrapper @ dotnet.native.wasm:0x62c057
$mono_interp_exec_method @ dotnet.native.wasm:0x61df69
$interp_runtime_invoke @ dotnet.native.wasm:0x62d96c
$mono_jit_runtime_invoke @ dotnet.native.wasm:0x742c70
$do_runtime_invoke @ dotnet.native.wasm:0x7034d0
$mono_runtime_invoke_checked @ dotnet.native.wasm:0x70346a
$mono_runtime_try_invoke_byrefs @ dotnet.native.wasm:0x709b83
$ves_icall_InternalInvoke @ dotnet.native.wasm:0x6cee04
$ves_icall_InternalInvoke_raw @ dotnet.native.wasm:0x6d7c7b
$do_icall @ dotnet.native.wasm:0x6311cb
$do_icall_wrapper @ dotnet.native.wasm:0x62c057
$mono_interp_exec_method @ dotnet.native.wasm:0x61df69
$interp_runtime_invoke @ dotnet.native.wasm:0x62d96c
$mono_jit_runtime_invoke @ dotnet.native.wasm:0x742c70
$do_runtime_invoke @ dotnet.native.wasm:0x7034d0
$mono_runtime_try_invoke @ dotnet.native.wasm:0x703f50
$mono_runtime_invoke @ dotnet.native.wasm:0x706acd
$mono_wasm_invoke_method_bound @ dotnet.native.wasm:0x8d87bf
(anonymous) @ dotnet.native.js:936
ccall @ dotnet.native.js:8977
(anonymous) @ dotnet.native.js:8996
kr @ invoke-cs.ts:273
l.javaScriptExports.call_entry_point @ managed-exports.ts:60
Fc @ run.ts:44
(anonymous) @ main.js:13

while calling the method window.miniaudioModule._sf_allocate_context directly from browser console just works fine and return this (I assume this is what a pointer seems in javascript),

(...args) => {
    assert(runtimeInitialized, `native function \`${name}\` called before runtime initialization`);
    var f = wasmExports[name];
    assert(f, `exported native function \`${name}\…

[sandreas]

Currently, it loads, but on calling methods like AllocateContext from C# code, which returns a pointer nint/IntPtr, I got this error in the browser console.

While this may be a problem in your code, it might also be a problem in C# WASM for specific systems (see dotnet/runtime#105893). However, it may take some time until I can take a look - pretty busy right now. Let's hope for the best.

Here's another interesting link I found: https://stackoverflow.com/questions/57938081/blazor-preview-9-mono-wasm-memory-access-out-of-bounds-max-string-size-for-dotn

Did you already consult an LLM?