Next (v1): making complete compatible API

[dy]

Just outline possible project strategies, as mentioned here.

1. Do nothing

With the time project becomes a historical artifact (if not already), a memorial of volunteering OSS efforts.

2. Archive the project

We're not qualified for really optimal implementation, there needs to be a serious sponsor and full-time engagement, just check @chrisguttandin work at standardized-audio-context.

3. Finish current code

Make minimally compatible API with current approach.
👍🏼 Any JS platform (see QuickJS, Duktape)
👍🏼 Can be used as polyfill
👎🏼 Unlikely to be maintained

4. Reuse web-audio-engine

👍🏼 That seems to be more complete
👎🏼 That's not maintained either

5. Wait for successor eg. web-audio-api-rs

👍🏼 Hope
👎🏼 Rust can be 150 times slower
👎🏼 Needs to be compiled to WASM

6. Bindings like node-audio, labsound

👎🏼 Binding = no way to run in browser

[dy]

After discussion with @stagas about wat-compiler and mono it became apparent that the right way to organize code is via compiled wasm files.

7. WASM binaries

👍🏼 Best possible performance
👍🏼 Cross-platform compat
👍🏼 Available for browser
👍🏼 With AudioWorklet support enables cross-platform audio modules
👍🏼 Perfect test-case for mono/compatible syntax

[jazz-soft]

If we want it to work headless, we probably cannot use WASM...

[dy]

Why? Node/browser support wasm frictionlessly

[jazz-soft]

My knowledge may be outdated then :)