LabSound is a C++ audio graph forked from WebKit's WebAudio

A fork of WebKit, which explains both the API and the code

LabSound originated as a fork of WebKit's WebAudio implementation, as used in Google's Chrome and Apple's Safari, and it implements many aspects of the WebAudio specification while extending its functionality with an improved API, new graph nodes, bugfixes and performance improvements. That lineage is the single most useful thing to know about the project. A developer who has written WebAudio in a browser already knows the node vocabulary, and a developer who has read the WebKit implementation already knows the code. The repository layout matches a library rather than an application, with include/ for the public headers, src/ for the implementation, cmake/ for the build files, third_party/ for vendored dependencies, examples/ for samples, and a qmake/ directory for the alternative build system, alongside a labsoundpy/ directory for Python bindings. The README also warns that LabSound does not maintain full compatibility with the spec, so a WebAudio developer should treat the API as familiar rather than identical.

The node list is where the extensions show

The feature list is a catalogue of graph nodes rather than a list of platform claims. There is compatibility with the WebAudio API itself, and then the additions. Audio asset loading goes through libnyquist, which is also what decodes the files for the audio texture tool. Binaural audio is supported through the IRCAM HRTF database, and the effect and generator nodes include ADSR, noise and stereo delay among others. There is a compile-time arbitrary function node for DSP processing, which is the feature that turns the graph from a fixed set of processors into a programmable one, and basic signal analysis nodes for time and frequency. An input node handles the microphone. There is non-realtime graph processing with wav export, which is what you need for offline rendering rather than live playback, SIMD-accelerated channel mixing routines, and a thread safety model for multi-threaded applications such as a GUI. That last item is the one that decides whether the library fits a real time application.

Building it means a backend choice on Linux and a network fetch on every platform

Users are expected to compile LabSound from source, and the dependency story is the practical part. Most dependencies are vendored as code in the repository under third_party/, including libsamplerate, kissfft and ooura. The remaining two, libnyquist and miniaudio, are downloaded automatically by CMake via FetchContent during the configure step, so a plain git clone is all that is needed and there are no git submodules and --recursive is not required. Because of that fetch, network access is needed the first time you configure a fresh build directory, and to build against a local checkout instead you pass -DLIBNYQUIST_SOURCE_DIR=/path/to/libnyquist and/or -DMINIAUDIO_SOURCE_DIR=/path/to/miniaudio. LabSound and libnyquist require a C++14 or greater compiler. The CMakeLists.txt is at the root and the associated CMake files are in the cmake/ subfolder, and the README is careful to note that using a nested build directory is illustrative rather than required.

Linux needs you to pick a backend, and Raspberry Pi means ALSA

On macOS and Windows the build is a plain configure and build.

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=../../labsound-distro ..
cmake --build . --target install --config Release

On Linux a backend must be selected, using one of ALSA, Pulse or Jack, and the ALSA build looks like this.

mkdir build
cd build
cmake -DLABSOUND_ASOUND=1 ..
cmake --build . --target install --config Release

On Raspberry Pi, as on Linux, a backend must be selected, the currently tested configuration is ALSA, and the asound development libraries have to be installed first.

sudo apt install libasound2-dev

The iOS build uses a separate toolchain file.

mkdir build
cd build
cmake -G "Xcode" -DCMAKE_TOOLCHAIN_FILE=../cmake/ios-toolchain.cmake -DCMAKE_INSTALL_PREFIX=../../labsound-distro-ios ..
cmake --build . --target install --config Release

The iOS path is worth flagging because the platform list in the README separates what is tested from what was once demonstrated. LabSound is currently tested on Windows 10, on macOS 10.10 through current, and on Ubuntu 18.04 using the ALSA and Pulse backends, and the README notes that in the past it has been demonstrated to work on iOS, Android, and Linux via JACK. So the Raspberry Pi and iOS instructions are real, but the tested set is narrower.

Linking means pulling in platform frameworks by hand

The integration instructions are explicit about what an application has to bring with it. On macOS you link liblabsound.a, and new applications also require Cocoa, Accelerate, CoreAudio, AudioUnit, AudioToolbox and libnyquist.a. On Windows you link labsound.lib and also need dsound.lib, dxguid.lib, winmm.lib and libnyquist.lib. LabSound requires symbols from libnyquist even though the CMake build compiles that dependency alongside the core library, so a static link still pulls in the whole of it. For convenience, LabSound.h is used as an index header file with all public nodes included, which is the one shortcut a new user should take rather than including headers one at a time. There is one runtime wrinkle that is easy to miss. LabSound includes an HRTF implementation, and using it creates an additional dependency on a folder of impulse wav files, so the PannerNode constructor takes an additional path to the sample directory relative to the current working directory.

audiotexture is a small tool with a specific purpose

One of the more interesting things in the repository is a command line utility rather than part of the engine. audiotexture renders an audio file to a PNG for visualisation, and the stated use is lining up animation to a dialogue track, or cheaply pulling event peaks from a texture instead of re-running signal processing. The signal is split into three frequency bands, low for voicing and body, mid for vowel formants, and high for sibilants and plosive transients, each compressed and then mapped to the red, green and blue channels of a time versus magnitude image. Every column is a time slice drawn as a two tone bar, a smoothed RMS energy body capped by a sharp peak tip, so the envelope stays readable while transient events remain precisely located, and a shadow lifting colour curve brings out quiet detail such as breath and room tone without distorting bar heights.

audiotexture <input-audio> [output.png] [width] [height] [mirror] [overlap] [gamma]

The arguments are documented with defaults, so width and height default to 1024 and 256, mirror defaults to 0 and fills symmetrically about the centre for a waveform pulse look when set to 1, overlap is the RMS smoothing window as a multiple of the per-column time slice and must be at least 1.0, and gamma defaults to 1.5 as a colour shadow lift where a value above 1 brightens dim detail and 1.0 disables it. The input is a wav, ogg, flac or mp3 file decoded by libnyquist, and the output path defaults to the input name with a .png extension. The reusable pieces, the TextureRecorderNode sink and the AudioTextureFixture graph helper, live in LabSound/extended/TextureRecorderNode.h.

Where LabSound is the wrong tool

The first limit is that a browser already has this. If the target is a web page, the WebAudio API is there, it is maintained by the browser vendor, and there is no reason to port a C++ fork of it into a WebAssembly build when the original is what the platform ships. The second is the maintenance gap, and it is the one to weigh carefully. The most recent tag is v1.2.0 from February 2023, with v1.1.0 from October 2022 and v1.0.1 from April 2021 before it, and the last push was on 2026-08-07, so the tree is being touched while the release line is not. A project that needs a packaged version with security fixes and a stated support policy should look elsewhere. The third is that this is a static library with platform specific linking requirements, no submodules but a configure-time network fetch, and a HRTF sample directory that has to be shipped alongside your binary. That is a lot of integration surface for what it buys. The fourth is scope, which is the audio graph itself. LabSound is not a mixing desk, not a plugin format implementation and not a codec library, and the example projects are the best guide to how far it goes.

Editorial conclusion

LabSound suits a native application that needs a WebAudio-shaped graph without a browser, a game that wants audio nodes it can drive from a real time thread, and a developer who wants a readable fork of a specification implementation rather than a black box. It is the wrong choice for web development, since the browser already has the WebAudio API, and it is the wrong choice for a project that needs a maintained upstream, because the last release was v1.2.0 in February 2023 while the last push was on 2026-08-07, so you are building on a project whose release line and working tree have diverged. Before building, read the dependency notes, because libnyquist and miniaudio are fetched by CMake at configure time and you need network access for the first configure. The last push was on 2026-08-07 and the newest tag is v1.2.0 from 2023-02-07.

Frequently asked questions

Official sources

1. Issues
2. LabSound/LabSound on GitHub
3. Project website
4. README
5. Releases