Tracking JUCE For WASM

Hi,All:

I am working on juce 7 to wasm now, planing core audio-related modules supports:

  1. juce::juce_core
  2. juce::juce_audio_devices
  3. juce::juce_dsp
  4. juce::juce_audio_processors
  5. juce::juce_audio_formats

Plan

  1. using wasm audio worklets port audio device. Wasm Audio Worklets API — Emscripten 3.1.44-git (dev) documentation
  2. using Web MIDI API webmidi API port midi device.
5 Likes

Fun! Good luck! We will be tracking your progress and can serve as a test point when you need it …

09/08-2023 updates

  • successful port AudioIODevice to wasm web audio worklet, and can be playing noise.

the example works fine;

    auto deviceManager = new juce::AudioDeviceManager();
    auto& types = deviceManager->getAvailableDeviceTypes();
    auto webAudio = types[0];
    auto device = webAudio->createDevice("O","I");
    device->open(1,1,44100,256);
    device->start(nullptr);

in the next time, I will be try to point MIDI related stuffs.

1 Like

I am working on build tracktion engine for wasm now, and it’s successful build wasm file, fixed all compile-time error, but a lots mock impls, then I will:

  1. intergate a synth plugin.
  2. make a single midi track project works.

wasm file tooooo big now.

Do you have this on a branch somewhere I can test with?

There are ways to shrink wasm code size, see

Optimizing Code — Emscripten 3.1.45-git (dev) documentation

I have not pushed it to a public area now, I will try to test the basic feature first in the next few days.

  • A special JUCE branch.
  • A special Trackation Engine branch.

yes, it’s looks good. thanks.

after wasm-strip, wasm file size reduces to 6MB, it’s should be very well.

There are a lot of native methods that need to be implemented inside JUCE, and in the current version most of them are done with empty implementations (except audio device / midi device) in order to pass compilation as soon as possible. I am thinking about the implementation of the following modules:

1. file system.

Chrome File Access API allows users to open a picker choose 1 or more files, and then read and write. looks like it’s fine working for project file. But it can’t actively read or write files, so it doesn’t work for audio files needed by midi plugins (e.g. sf /sfz player). I’m thinking of a technical solution for reading files from the server quickly so that nfs over HTTP or nfs over Websocket can be realized.

Local FS over Chrome File Access API and NFS over HTTP it’s both needed.

2. Thread Pool
The fact that wasm allows the use of pthread, so thread pools for multi-cpu processing are possible, is my next goal.

All the parts about the GUI I’m going to skip, mainly because I’ve currently chosen QT as my UI solution and have tested that it works well, so I’m not going to spend time on the parts about real GUI rendering.