WASM Supports?
imiskolee opened this issue · 9 comments
hi,team:
Did anyone tested it on wasm platform?
There is https://github.com/sfztools/sfizz-webaudio/, I think it's somewhat a WIP.
It works, although it needs a patch because the system expects to read from a real filesystem using standard commands. I guess the "better" way would be to have some virtual filesystem approach available.
It works, although it needs a patch because the system expects to read from a real filesystem using standard commands. I guess the "better" way would be to have some virtual filesystem approach available.
yes. I think we can point fs operator outside, somethings like sfizz_set_read_func() sfizz_set_write_func(). then we can use custom fs operation function impl them.
Yes. It's a more involved piece of work though, and I don't have so much expertise in how such interface should work with Web technologies. I do have some experience in how it could interface with Android walled garden and base myself on that.
I most probably won't have the time to accomplish this soon, but if you feel up to the task I can offer some guidance.
we can still support old style blocking calls in wasm, we just need to load entire sfz as resource.
like the stuff in https://minicardinal.kx.studio/ which loads many different files from the filesystem, but all works here seamlessly because the resources are loaded before the application runs so by the time the wasm is active any blocking filesystem call works the same as in a regular machine.
and regarding threads and sync, things seem to have evolve quite well in that regard.
both firefox and chrome support the needed bits for pthreads in emscripten, but still requires a secure context (https page) with specific server-side headers set.
the main issue for wasm at the moment is that MIDI can only be done on the main thread, even if we use audio worklets to handle audio outside the main thread.
this has a very high chance of jitter and makes it unsuitable for a pro-audio usage.
if we ignore live midi handling, then perhaps it is a good enough of a platform to target.
@falkTX thanks for these tips, I have very little knowledge about web technologies and just hacked around the (now non-working) wasm demo in between jobs so I'm just a big newbie. The source for the minicardinal site is available somewhere?
The midi information is interesting. At least for one of my desired use cases (drum backing tracks) latency is less of an issue. To demo/try SFZ files, it should also be okay-ish.
and regarding threads and sync, things seem to have evolve quite well in that regard. both firefox and chrome support the needed bits for pthreads in emscripten, but still requires a secure context (https page) with specific server-side headers set.
the main issue for wasm at the moment is that MIDI can only be done on the main thread, even if we use audio worklets to handle audio outside the main thread. this has a very high chance of jitter and makes it unsuitable for a pro-audio usage. if we ignore live midi handling, then perhaps it is a good enough of a platform to target.
In fact, I am working on the latest JUCE migrate to WASM, the audio device callback is works with openal. So, I will trying make the sfz player as JUCE Plugin for play first.
you dont need a library to abstract those, web audio via javascript is not too complex.
though for now I only used script processors and not the new worklets, mostly for compatibility reasons.
my WIP implementation is on https://github.com/DISTRHO/DPF/blob/develop/distrho/src/jackbridge/WebBridge.hpp, this is what makes Cardinal on the web do its thing and also https://aida.kx.studio/ as a more recent example (built directly from AIDA-X)