> Fibers is the highest priority library for us to get running with Hoot.
well I'm very happy to hear that! There's very specific abstractions I want to work with for exploring stuff and that makes it easier. On Mon, Dec 11, 2023, 11:39 AM Thompson, David <dthomps...@worcester.edu> wrote: > 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 >
