[Csnd] Webaudio Csound - 6.17.0-beta1

Hi All,

Hlodver and I have been working on the new version of Webaudio Csound
for a while now and have put up a new 6.17.0-beta1 version:

It should be API compatible with the 6.16.0-beta versions if you were
using those. API documentation can be viewed at the link above. We had
planned to do a separate website with tutorials on how to use the
WebAudio Csound API but have not yet gotten to it. We have done some
tests with other webaudio csound-based projects and so far things look
good, but would appreciate others testing this.

Once this release is complete, we will look at updating the web-ide to use it.

Latest code has been merged into the develop branch of Csound.

Thanks and all best,

p.s. - Happy new year!

Csound mailing list
Send bugs reports to
        Issues · csound/csound · GitHub
Discussions of bugs and features can be posted here

Thanks guys. For me, the webaudio stuff has been the highlight of Csound development in 2021. I’m looking forward to working with the latest version.

yes, congrats to all.

What’s the toolchain to build and test this code? There’s the nchnls=1 behaviour I need to check to see if it needs fixing (currently only feeds the left out, but should go to both.)

Prof. Victor Lazzarini
Maynooth University

This is the underlying toolchain: https://github.com/WebAssembly/wasi-sdk

It is using patches to activate Emscripten dynamic loading mechanism.
These patches and build scripts are tied together with nix package manager.
Which makes them very reproducible and less prone to random faults, but
does make it harder to get it running natively. I also think custom Clang compiler
isn’t something that is nice to have running globally on one’s computer.
Long story short, I recommend building with the Docker image, I think wasi-libc
will get better supported with Clang, so that it can just build without any customization,
not sure if Clang is there yet today.

Another alternative is to build csound statically like the older Emscripted did, that would
not require any magic, and wasi-sdk should in that case work out of the box as is. The javascript
code has mechanism to detect whether it’s running csound from statical linking or dynamic one,
and it should support both without problems.
The end product is a single javascript asset that will have the binary output inlined as base64 string.
It’s currently using google-closure-compiler (previously we started with Rollup), that depends on
java being available on your system, other than that, it’s yarn and nodejs for building the js asset.

If in doubt, there is a github workflow action that now runs to build and test this new wasm,
so it’s a good point of reference for how to build the wasm asset from scratch, also,
the build also stores a zip file containing the build artefacts,

so in theory it is possible to download this lib.zip file and skip the whole clang sdk process and use the assets
from the github workflow.

Is closure required for running or just for building?

It does look fairly more complex to build locally than the old emscripten build that was just a shell script and cmake.

Prof. Victor Lazzarini
Maynooth University

The build is two parts.

  1. native wasm: which will be the basis for any runtime supporting wasm (wasmtime/wasm3/nodejs/v8…)
  2. browser bundle: which packs the binary as inlined base64 and includes bindings for webaudio

Closure is required to build the browser bundle, after the csound.js exists in dist directory, it’s then only a matter
of serving it like any js library.

The complexity imo, revolves around step1, and for any javascript contributor, this step is totally skip-able, as
you can cd into wasm/browser, do yarn install, and then yarn build. The binaries are published to npm
as its own package @csound/wasm while the browser bindings are another @csound/browser.

Should note that if you have the nix package manager installed (https://nixos.org/), building is very simple (on macOS at least). Once you install nix, you go into wasm folder and type “yarn; yarn build” for the wasm and cd into wasm/browser and type “yarn; yarn build”. That should be it I think. nix will download and compile all the dependencies (clang, llvm, libsndfile, wasi, etc.). It takes a while the first time building the wasm folder but after that it’s fairly quick.

ah, that’s very handy.

Does it use CMake? Do we need to worry about keeping things in sync with CMakeLists.txt?

Prof. Victor Lazzarini
Maynooth University

It doesn’t use CMake, but I think we should use it. It’s a bit of mess, I started off compiling csound file by file, to patch away issues that I was dealing with.
It makes wasm built easily fail if files are moved, renamed or added. But I think we should work on simplifying it and use CMake to build everything.
This is a big ugly point I forgot to add. But only until recently, I didn’t touch any file not under the wasm directory, so I applied hacky patches
shamelessly from the nix build process. But I believe the most important patches, most of which relating to mutex imports and c++ plugins,
are now in the csound proper source code, so the need to maintain a seperate list of source files isn’t as needed as it was when I started off.
I will make sure that eventually we are using CMake. If the wasm build fails, just ping me until this transition has been made, and I’ll fix.

I think it would be good if CMake can be used, otherwise we will need to keep the build in sync by hand. We’re doing it for Android and that is a pain because we forget and then have to fix a broken build.

Also there’s the other thing that some header files are auto generated by CMake, and if you use static versions of these, they may get out of sync too.

So if it’s possible to use CMake, we should do it as soon as we can.

Prof. Victor Lazzarini
Maynooth University