waveform: a live audio spectrum plugin for OBS Studio

What it is, and the one thing it does not do itself

Waveform is an audio spectral analysis plugin for OBS Studio, and the README states two things about its construction that explain most of the rest.

It is based on FFTW, the Fast Fourier Transform library, and it is optimized for AVX2 and FMA3.

That second point is the interesting one, because OBS Studio renders frames on a deadline. A spectrum visualisation that has to recompute a transform every frame is doing floating point work inside the render loop, and the difference between a scalar implementation and one using vectorised instructions is the difference between a visualisation that keeps up and one that stutters. AVX2 gives eight-wide float operations, and FMA3 fuses multiply and accumulate, so the butterfly stages of the transform get fewer instructions and fewer memory round trips.

The repository layout backs up the claim that this is a performance-minded project. There is a src/ directory for the plugin, a deps/ directory, a cmake/ directory, a CI/ directory, a data/ directory holding the interface assets, an installer/ directory, a pkg/ directory for packaging, and a THANKS file alongside a changelog.md.

There is a Mac and Linux CI badge in the README, which tells you the project is built and tested on those platforms automatically.

So this is a native C++ plugin that does live spectral analysis, and the interesting engineering is in making that analysis cheap enough to run every frame, and in shipping the result inside OBS rather than as a separate window.

The CMake options, and the three that are not what they look like

The options table is the most technical part of the README and the most useful, because several of the options are about how the plugin is packaged rather than how it behaves.

ENABLE_X86_SIMD enables runtime detection and dynamic dispatch for AVX, and it is on by default. Runtime detection with dynamic dispatch is the right approach for a plugin, because OBS runs on everything from a decade-old laptop to a modern desktop, and a plugin that assumes AVX2 simply refuses to start on the older machines. Dispatching at runtime means one binary covers both.

HAVE_OBS_PROP_ALPHA enables alpha in the color picker and may need to be disabled for very old OBS versions. That is a compatibility escape hatch for a host application feature the plugin uses, and the option to turn it off is what keeps it installable on older OBS releases.

PACKAGED_INSTALL uses a package manager friendly folder structure when installing, and it is Linux only.

The two FFTW options are the pair to read carefully. BUILTIN_FFTW builds FFTW from source and static links it, and it is forced with MSVC and otherwise off. STATIC_FFTW static links against a system-provided FFTW, off by default. So on Windows you always get a vendored FFTW, and on Linux and macOS you get the system library unless you ask otherwise, which is the opposite of the usual pattern and is a deliberate choice for a project that wants a working Windows build out of the box.

The MSVC-only options are about the runtime, not the plugin. STATIC_RUNTIME static links the CRT. EXTRA_OPTIMIZATIONS enables aggressive compiler optimizations through LTCG, the link time code generation.

And the two packaging options are MAKE_DEB for a Debian or Ubuntu package and MAKE_BUNDLE for a macOS bundle, both off by default.

Building on Linux, and the two distributions the README names

The Linux path is the well-trodden one, and the README gives complete instructions for two distributions.

The prerequisites are common: a C++ compiler, CMake and git, plus libobs-dev, libfftw3-dev and libfftw3-3 on Ubuntu 20.04.

# install build tools
sudo apt-get install build-essential git cmake

# install dependencies
sudo apt-get install libobs-dev libfftw3-dev libfftw3-3

# clone repo
git clone --recurse-submodules https://github.com/phandasm/waveform.git

# build in subfolder
mkdir waveform/build
cd waveform/build

# build
cmake ..
make
make install

The Fedora 41 instructions are the same shape with dnf, and they carry a prerequisite: OBS packages from RPM Fusion, with a pointer to the OBS wiki page on unofficial Linux builds. That is worth noting because it means the Fedora route depends on a third-party repository being configured before the build can find libobs.

The clone step uses --recurse-submodules, and the prerequisites section says to clone the repo with submodules that way, or if you already cloned without them, run git submodule update --init --recursive. The deps/ directory in the repository is where the submodule content lives, which is how FFTW and the other vendored pieces get in.

The last piece is the Flatpak rule, and it is a hard constraint rather than a preference. When using OBS from Flatpak, Waveform must be installed from Flatpak as well:

flatpak install flathub com.obsproject.Studio.Plugin.waveform

That is the Flatpak sandbox talking: a Flatpak OBS cannot load a plugin installed outside the sandbox, so the plugin has to come from Flatpak too. The naming, com.obsproject.Studio.Plugin.waveform, follows the convention of the OBS plugin repository.

Windows, where you have to build OBS Studio first

The Windows instructions are the ones that stop people, and the reason is stated in a single sentence. Waveform's only external dependency is libobs, so you'll need to build obs-studio separately and point CMake to it when building Waveform.

The pointer is given as a command line argument:

-DCMAKE_PREFIX_PATH="path/to/obs-studio/build_x64/libobs"

And there is a second path you may also need, the w32-pthreads library, which is under the obs-studio build directory at deps/w32-pthreads. So the build of the plugin depends on artefacts from a build of the host application, which is unusual for a plugin and is a direct consequence of the plugin linking against the host's own library rather than against a stable SDK.

The rest of the sequence is a standard CMake workflow. You create a build directory with mkdir build and cd build, you run cmake ../, and you build the solution by double-clicking the generated .sln file and going to Build then Build Solution, or with the Ctrl-Shift-B shortcut.

Installation is then a copy of two things into two different places. Copy waveform.dll and waveform.pdb to the 64bit plugin directory under the OBS Studio installation, and copy the contents of the data folder, which is the locale folder and the gradient.effect file in the waveform source directory, to the waveform directory under obs-plugins in the data folder of the OBS Studio installation.

The split is worth understanding. The DLL is the code, and the data directory is the interface resources and the gradient definition that controls how the spectrum is coloured. Keeping them separate means a colour change does not require a rebuild, and it is the same split the Flatpak package has to respect.

The compiler floor, and what the maintenance picture looks like

The minimum supported compilers are listed precisely, which is the kind of detail that tells you the project takes build reproducibility seriously.

GCC 10.1, Clang 11.0, and VS 2019 16.8.

Those are floors rather than suggestions, and they are not old floors. GCC 10 and Clang 11 are the versions where the C++ features this kind of code wants became reliably available, and pinning VS 2019 16.8 rather than a later 16.x matters because the MSVC toolset changed in ways that affect ABI between point releases.

The release history is regular and recent. v1.9.1 was published on 2026-07-14, v1.9.0 on 2026-07-12, and there is a v1.9.0-beta2 from 2026-07-05, so the 1.9 line was stabilised over about ten days in July 2026. The last push to the repository was on 2026-08-20 and the repository is not archived.

The project page is on the OBS Studio forum, at the resources thread for waveform, which tells you how OBS plugins are distributed in practice. The forum page, rather than a package registry, is where a user finds the build instructions and the discussion.

So the shape of the project is: a focused native plugin, a small dependency tree, a build that you run yourself against your own OBS, and a codebase that is small enough to read, which is appropriate for something whose entire feature is a spectrogram.

Editorial conclusion

Adopt Waveform if you stream audio and want a spectrum visualisation that is calculated live rather than a prerecorded visual, and if you are comfortable building a C++ plugin against your own OBS Studio build. Do not adopt it if you need a preset visual that works on a machine you do not control, because on Windows it means building libobs first and on Flatpak it means installing from Flatpak rather than copying files. Before you start, check the compiler floor, because the project requires GCC 10.1, Clang 11.0 or Visual Studio 2019 16.8, and read the CMake options table since several of them change what gets built rather than just how.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. phandasm/waveform on GitHub
3. Project website
4. README
5. Releases