On Mon, Dec 11, 2023 at 12:03 PM Daniel Skinner <dan...@dasa.cc> wrote: > > > I don't think I quite understand what's going on. Are you passing over > > WebAssembly.Instance objects as the event data to the AudioWorklet? > > Not the instance, but rather WebAssembly.Module via compileStreaming as the > instance is not serializable. > > > Could you just instantiate everything in the main "thread" and pass over > > ready to use instances? > > My understanding is no; modules on the other hand can be serialized and > passed to AudioWorklet via postMessage. Once there, they can be instantiated > in the worklet.
Ah, okay. That makes sense. I haven't used AudioWorklets before and it's been awhile since I've used Web Workers which have similar constraints. > In my research, this is a pervasive issue for projects targeting wasm that > stems from limited api availability in AudioWorklet (e.g. no networking, no > fetch due to thread priority given, other little things). It also appears the > situation is made intentional and won't be changing. > > see for example: > https://github.com/WebAudio/web-audio-api/issues/1439 > > https://github.com/rustwasm/wasm-pack/issues/689 > > or search "wasm audioworklet fetch" > > The situation in hoot could be improved by accounting for this and basing the > Scheme.load* of reflect.js around modules too instead of only fetchable > paths. What I did was the smallest diff possible to confirm workable by > adjusting instantiate_streaming and adding a Scheme.set_module_map but I dont > necessarily recommend this. Yeah, I think what we'd want is an alternate interface rather than overloading what instantiate_streaming does, but the general pattern of loading the module on the main thread and instantiating on the worker sounds like the way to go. > iirc and specific to AudioWorklet, the situation could be further improved by > making the contents of reflect.js work with import, but (again, iirc) the > import statement for AudioWorklet only currently works in firefox and I > didn't get a chance to see if its planned for other browsers; in this way, I > wouldn't need to copy/paste the contents into realtime_worklet.js reflect.js is pretty rudimentary right now. import support would be very nice. I'll file an issue on GitLab so we don't forget about it. > > I also noticed you are doing things with WebGL. You beat me to it. ;) > > it "just worked"! But I need to write up some helpers as I explore forms of > api design to do something more interesting. Yeah, it takes quite a bit of helper code to make something useful with OpenGL. > > At some point, I will be porting Chickadee to the web using WebGL and > Web Audio so your exploration here will help make that happen. > > I've only been writing scheme for like 5 weeks so it's my process for > learning. I read through Chickadee like 3 weeks back when researching > people's conventions and I appreciate you making that available. Oh neat, welcome to the world of Scheme, then! :) > What would be neat is to also get guile-fibers going (guile-fibers on desktop > platform is what got me to dive in to begin with). Fibers is the highest priority library for us to get running with Hoot. We're still working on how the module system is going to work (very tricky!) but when it does we're going to figure out how we port fibers. - Dave
