obs-pipewire-audio-capture adds application capture to OBS on Linux

Three sources where OBS normally gives you devices

obs-pipewire-audio-capture is a plugin that adds three sources for capturing audio outputs, inputs and applications using PipeWire. The README shows two screenshots, one of the device capture properties and one of the app capture properties, which tells you the plugin covers both of those categories.

The application source is the reason the plugin exists. OBS on Linux normally captures audio from a device, and a device source captures everything routed through it. If you want one application's sound and not the rest of the system, a device source gives you too much and you have to mute the other sources by hand. A PipeWire application source captures a single stream by application.

The project is written in C, the licence is GPL-2.0, and the homepage points at the OBS project forum thread for the plugin. The repository topics are audio, linux, obs-studio and pipewire, which is an accurate summary of the scope.

The audience is Linux users recording or streaming with OBS Studio who need finer control over what ends up in their audio mix than a device source allows.

The requirements are a PipeWire problem, not an OBS problem

The requirements section is short and the ordering of the constraints matters. OBS Studio 28.0 or later is required, and WirePlumber is required. PipeWire 0.3.62 or later is described as highly recommended, with an issue reference and a link to the upstream PipeWire issue.

Then comes the line that decides whether the plugin will work for you at all: for the plugin to be able to capture applications, PipeWire has to be set up to handle audio on the system.

For most applications the pipewire-pulse compatibility layer is enough, but the README also names pipewire-jack and pipewire-alsa, and it says that if applications are not showing up in the plugin, the system may be missing one of those components. That is a real failure mode: an application built against JACK or ALSA directly does not appear in the PipeWire graph unless the corresponding bridge is present.

So the diagnostic order matters. If a browser appears in the app list but a game does not, the missing piece is almost certainly pipewire-jack or pipewire-alsa rather than anything in OBS.

Flatpak users need a filesystem override

If OBS Studio comes from Flatpak, the plugin is published on Flathub and installs with one command:

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

The sandbox is where the second problem appears. The README says that if the sources show no devices or apps, you should run an override command and restart OBS Studio:

flatpak override --filesystem=xdg-run/pipewire-0 com.obsproject.Studio

The Flatpak sandbox cannot see the PipeWire runtime socket by default, so the plugin inside the sandbox has nothing to connect to. The override grants access to the xdg-run/pipewire-0 directory where that socket lives, and it is the difference between a plugin that lists your applications and one that lists nothing.

This is a filesystem permission grant to the whole OBS application, not a narrow one, and it applies to the com.obsproject.Studio application id rather than to the plugin. Worth reading before you run it on a machine where OBS handles sensitive media, and worth remembering if you move to a different Flatpak OBS package, since the application id changes.

The manual install is a tarball into the plugins folder

For anything that is not the Flatpak build of OBS, the install is manual and the steps are spelled out. You get the linux-pipewire-audio-(version).tar.gz archive from the latest release, open OBS Studio, go to File and click Show Settings Folder, create a plugins folder inside it if it does not exist, extract the archive there, and restart OBS Studio.

The expected layout is given in the README, and the plugin file itself sits two directories deep:

.../obs-studio/plugins
├── linux-pipewire-audio
│   ├── bin
│   │   └── 64bit
│   │       └── linux-pipewire-audio.so
│   └── data
│       └── locale
│           ...

The 64bit directory is the one detail that catches people out. The shared object is architecture specific and has to end up in the bin/64bit path, not at the top of the plugin folder, or OBS will not load it. The locale directory carries the translations.

Because the plugin lives in the user's settings folder rather than in a system location, this is a per user install. That also means a fresh OBS profile or a different user account needs it installed again.

Building it for development takes CMake and three dev packages

The development build is the part of the README aimed at people who want to change the plugin rather than use it. The prerequisites are CMake, PipeWire and the OBS Studio or libobs development packages, and then three commands in the repository root:

cmake -B build -DCMAKE_INSTALL_PREFIX="/usr" -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build build
# To install it system-wide:
cmake --install build

The install prefix of /usr means the system-wide install puts the plugin where OBS expects system plugins to live, which is the counterpart to the per user folder used by the release archive. The RelWithDebInfo build type is the usual choice for a plugin you intend to debug, since it keeps symbols while optimising.

The repository layout backs this up. There is a CMakeLists.txt at the root, a cmake directory for the build logic, a src directory for the C sources, a data directory for the locale and other packaged files, and assets for the screenshots. A .clang-format file and an .editorconfig file sit alongside, so the formatting rules are shared between the compiler and the editor.

Upstream inclusion would remove the whole install problem

The last section of the README says the plugin is currently in the process of being worked on to merge into upstream OBS Studio, with a link to the pull request against the OBS repository.

That single sentence is the most important strategic fact in the document. If the plugin lands upstream, the manual tarball extraction disappears, the Flatpak override becomes somebody else's problem, and the version pinning becomes an OBS release rather than a GitHub release. For a user, that is the difference between a plugin you install and a feature that ships with the application.

The repository is not archived and the last push was on 2026-08-06, so the work on the plugin is continuing. The release tags tell a similar story: 1.2.1 on 2025-09-05, 1.2.0 on 2025-02-14 and 1.1.5 on 2024-07-14.

Until the merge happens, the practical reality is that the plugin is maintained separately from OBS and its compatibility with new OBS releases is something the plugin author has to chase. The GPL-2.0 licence is what makes that merge possible at all, and any specific compliance question about it belongs with your own counsel.

Editorial conclusion

obs-pipewire-audio-capture is the right tool for an OBS user on Linux who needs to record a single application rather than a whole device, since a PipeWire application source is something the built in OBS sources do not provide. It is the wrong choice if your system does not already route application audio through PipeWire, because the plugin cannot capture what the audio server never sees. Before installing it, check that WirePlumber is in place and that PipeWire is 0.3.62 or later, which is highly recommended, install the Flathub plugin if OBS comes from Flatpak, and run the flatpak override command if the sources list no devices or apps.

Frequently asked questions

Official sources

1. dimtpap/obs-pipewire-audio-capture on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases