Can't seem to capture module-filter-chain as audio input.

[KynikossDragonn]

When I try to setup my microphone through this plugin, the "Default" and "Blue Snowball" works, but when I try to select "Voice Modulation Source", I still hear the regular unaltered microphone.

When I close OBS and restart it after tying to select "Voice Modulation Source", I hear absolutely nothing until I go into the options and manually pick "Default" or "Blue Snowball" again.

Attempting to re-select "Voice Modulation Source" afterwards does not properly start capturing the proper audio.

OBS's default PulseAudio handling (as well as PulseAudio itself in every other program), JACK (tested in Audacity), etc work fine.

pavucontrol: Audacity with JACK:

I have a log of the PipeWire instance hosting the Filter Chain if it'll be of any use: filterchaindebug.log.gz

[KynikossDragonn]

Okay I think I might have a idea what's going on here...

I'm using a fairly stock PipeWire (0.3.55) setup, and using WirePlumber as the session manager.

When I examine everything in Helvum, I noticed.... there's a massive ambiguity occurring with the PipeWire plugin: I had to manually re-wire everything in Helvum to get the intended results to happen, and if I restart OBS everything immediately and promptly breaks. WirePlumber starts assigning every single instance of "OBS Studio" to the monitor of my desktop audio.

WirePlumber ends up storing this section in the ~/.local/state/restore-stream file:

Input/Audio:media.role:Production:channelMap=FL;FR;
Input/Audio:media.role:Production:channelVolumes=1.0;1.0;
Input/Audio:media.role:Production:mute=false
Input/Audio:media.role:Production:target=alsa_output.pci-0000_00_1f.3.analog-stereo
Input/Audio:media.role:Production:volume=1.0

I don't know much C and C++ but I took a look into pipewire-audio.c at line 449:

struct pw_properties *obs_pw_audio_stream_properties(bool capture_sink)
{
    return pw_properties_new(
        PW_KEY_NODE_NAME, "OBS Studio", PW_KEY_NODE_DESCRIPTION,
        "OBS Audio Capture", PW_KEY_APP_NAME, "OBS Studio",
        PW_KEY_MEDIA_TYPE, "Audio", PW_KEY_MEDIA_CATEGORY, "Capture",
        PW_KEY_MEDIA_ROLE, "Production", PW_KEY_STREAM_CAPTURE_SINK,
        capture_sink ? "true" : "false", NULL);
}

Is it correct to be giving the nodes the same exact name and description? I can understand giving them the same exact app name, but I think what's causing my problems is the nodes and description being identical. Another program I use; Mumble, does not appear to give it's playback and capture nodes identical ambiguous names and I cannot run into a fault trying to use my filter-chain with Mumble once the appropriate targets are setup.

[dimtpap]

Can you share your filter chain config

[KynikossDragonn]

Sure, here it is: voicemod.conf.gz

Place in ~/.config/pipewire/filter-chain.conf.d/ and run a pipewire instance with -c filter-chain.conf as according to the changes added in PipeWire 0.3.55.

I'm using LADSPA plugins available from here: https://github.com/swh/ladspa (On Void Linux this is packaged as "swh-plugins")

The filter chain documentation in PipeWire's wiki is still very confusing to read, I based my conf out of one of the preexisting ones included as examples.

[dimtpap]

The plugin expects a node to report the number of its channels and this doesn't. You can add audio.channels = (number of channels) in capture.props and playback.props as a temporary workaround

[KynikossDragonn]

I actually originally left that out of the filter chain definition because I kept getting errors, but I guess I'll try that, thanks.

Another problem would be why wireplumber's "restore-stream" system is messing up the plugin and assigning the wrong kind of channels and forcing every instance of it to one specific device if I ever touch the plugin's options at all. (If I create a PipeWire plugin source, and do not select anything other than "Default" wireplumber doesn't cause this bug, bu then I have to use Helvum to make the appropriate selections which wireplumber seems oblivious of!)

EDIT: I can't seem to manage to reproduce the wireplumber misbehaviour anymore after a recent system update and clearing several things out of the "restore-stream" file, so I'm going to close the issue, thanks for telling me about the audio.channels option, it seems to work correctly!