Virtual Surround Manager: Please help with setting PipeWire metadata

Berny23 · June 14, 2026, 3:52pm

Hey guys, I developed a software that interacts with the PipeWire C API to re-route audio to a virtual sink. This works by setting PW_KEY_TARGET_OBJECT in the metadata.

My AppImage and AUR package work normally. Only the Flatpak build has this PipeWire issue. There, the UI, filter chain node creation and audio source node detection work fine. However, setting the metadata for actual routing does absolutely nothing and the connection is not visible in coppwr. But this should actually work, because EasyEffects and other apps also support Flatpak and definitely change node metadata.

It should look like this in coppwr when everything works:

Flatpak manifest file: virtual-surround-manager/dist/flatpak/de.berny23.virtual_surround_manager.Devel.json at main · Berny23/virtual-surround-manager · GitHub

How to build:

Clone repository: git clone https://github.com/Berny23/virtual-surround-manager.git
Change directory: cd virtual-surround-manager
Build the flatpak: flatpak-builder --force-clean --user --install-deps-from=flathub --repo=repo --install flatpak_build ./dist/flatpak/de.berny23.virtual_surround_manager.Devel.json
Run the program: flatpak run de.berny23.virtual_surround_manager

Please help me with this, so I can submit it to FlatHub. Thanks.

Stephen-Hazel · June 21, 2026, 4:36pm

it’s crickets around here isn’t it - I don’t get why that is ???

I’m able to use pipewire with my pianocheetah flatpak (in the next release I’m working on - not in the current release).

My finish args are:

“finish-args”: [
“–filesystem=host”,
“–filesystem=xdg-run/pipewire-0”,
“–share=ipc”,
“–share=network”,
“–device=dri”,
“–socket=wayland”,
“–socket=fallback-x11”,
“–socket=pulseaudio”
],

So looks like the diffs between us is my --filesystem=host (probably not necessary for you - I just don’t like the weird paths that show up when you don’t use it)

and share=network (I think that’s necessary to use usb midi devices? as with many flatpak things i’m unsure)

and socket=pulseaudio - I think this is all you’ll need it’s the ONE flatpak flag telling the system that you’re using audio and not particularly pulseaudio just any audio.

This is not well doc’d (flatpak dev docs are voluminous but not very comprehensive as with all things linux) and getting help is rough (again - as with all things linux sigh)

I mean ole claude may make some crappy code (if you don’t clean it up) but I’ve found it verrrrry helpful in getting past the very limited docs of linux/kde/flatpak/etc etc.

good luck to ya

…Steve https://shaz.app

Berny23 · June 21, 2026, 5:40pm

Thanks for your answer. I tried all your arguments, but it didn’t change anything.

To clarify: Everything regarding PipeWire works, except actually routing the audio to my sink by setting the metadata!

I even have the same normal looking debug logs as with a native installation:

create_virtual_surround_module: Creating module with WAV path '/home/berny23/.var/app/de.berny23.virtual_surround_manager/data/virtual-surround-manager/hrir_wav/sbx100.wav'
create_virtual_surround_module: Successfully created module
Enabled routing
registry_event_global: Node 'Firefox' with ID 229 routed to sink 'effect_input.virtual-surround-manager'.

Everything indicates it should work, but it actually does not route the audio. It does not create the route from the app (Firefox here) to my virtual sink. See in coppwr:

This is how it looks like in my native installation and AppImage:

nbenitez · July 1, 2026, 12:17am

Maybe run under strace to see if failed to open some file..

Berny23 · July 1, 2026, 10:16am

Strace didn’t help, but I found this debug variable: PIPEWIRE_DEBUG=5

This line only appears for the Flatpak version:

[D][12:13:14.363404] pw.core | [ core.c: 64 core_event_error()] 0x5569d607df60: proxy 0x7f63d4007040 id:3: bound:40 seq:14 res:-1 (Die Operation ist nicht erlaubt) msg:“set property error for id 229: Die Operation ist nicht erlaubt”

Also testing it with the PipeWire CLI, it simply refuses to write any metadata:

PIPEWIRE_DEBUG=1 flatpak run --command=pw-metadata de.berny23.virtual_surround_manager -n default 0 target.object test

Found “default” metadata 40
set property: id:0 key:target.object value:test type:(null)
[E][12:49:07.791337] default | [ pw-metadata.c: 147 on_core_error()] error id:3 seq:5 res:-1 (Die Operation ist nicht erlaubt): set property error for id 0: Die Operation ist nicht erlaubt

However, the same thing happens when running it in the EasyEffects Flatpak: PIPEWIRE_DEBUG=1 flatpak run --command=pw-metadata com.github.wwmm.easyeffects -n default 0 target.object test

Still, EasyEffects successfully writes metadata to any host sources. Why does it work?

I’m doing the same thing as EasyEffects, but in my case, the line just doesn’t work in a Flatpak: pw_metadata_set_property(manager->metadata, id, PW_KEY_TARGET_OBJECT, “Spa:String:JSON”, manager->capture_node_name);

And here the line from the EasyEffects source code: pw_metadata_set_property(metadata, id, key, type, value);

The function is called like this: metadata_manager.set_property(origin_id, “target.object”, “Spa:Id”, util::to_string(target_serial).c_str());

As you guys can see, it’s exactly the same property (target.object) I also use. I even tried using the node ID instead of the node name, but writing just fails regardless.

nbenitez · July 1, 2026, 2:24pm

I run your question to Grok, including asking how EasyEffects works.. have a look it may put you in the right direction:

I’m not experienced on Pipeware so cannot help you further. Good luck.

The easyeffects question cannot link it, so I pasted it here:

gist.github.com

https://gist.github.com/nbenitez/171081e87684375b62f5e1927b1a503d

gistfile1.txt

EasyEffects works fine in Flatpak (and everywhere) because it does not use module-pipe-tunnel or any FIFO/named pipe at all.
How EasyEffects does it correctly
EasyEffects creates native PipeWire virtual devices (a sink + a source) using PipeWire’s built-in support.null-audio-sink mechanism (via the adapter factory or by asking the PipeWire core to load the equivalent module).
These are proper first-class nodes in the PipeWire graph — exactly like a hardware sink or a module-null-sink you would create with pw-cli or in pipewire.conf.d/. No filesystem path, no /tmp/fifo_*, no pipe.filename property.
Because there is no external FIFO involved, there are zero sandboxing problems with Flatpak’s private /tmp or restricted filesystem view.
Key points from EasyEffects’ approach

It creates its virtual sink/source when it starts (and keeps them alive as long as the process runs — or with background permission in Flatpak).
It then uses PipeWire’s native linking + metadata APIs (and WirePlumber integration) to route streams:
“Process all output streams” → automatically moves matching streams to its virtual sink.

This file has been truncated. show original

Also related (I think you may be using this module which cannot work in Flatpak as uses a unix pipe): PipeWire: Unix Pipe Tunnel

Berny23 · July 1, 2026, 4:15pm

I already tried asking all the big AI models, even providing output and the source archives, but it didn’t help. This is a problem that’s too specific for a stochastic machine to solve, I guess.

But I’m very glad to say: I finally found the solution!

With some classic documentation reading, code comparison and googling (or DuckDuckGo-ing), I found the pretty hidden PipeWire docs about access control: PipeWire: Access Control

It was only these three lines I had to add/change:

pw_properties *props = pw_properties_new(nullptr, nullptr);
pw_properties_set(props, PW_KEY_MEDIA_CATEGORY, "Manager");
context = pw_context_new(pw_thread_loop_get_loop(thread_loop), props, 0);

Commit: Finally fix setting metadata in Flatpak! · Berny23/virtual-surround-manager@09f8b3e · GitHub

So easy, yet so hard to find and diagnose for a PipeWire beginner.