"Disable Noise Suppression" unloads all instances of PA modules, not just those created by Cadmus

[mainmachine]

Clicking "Disable Noise Suppression" unloads all instances of module-loopback, module-null-sink, module-ladspa-sink and module-remap-source, even if they are unrelated to Cadmus.

I use a global DRC (dynamic range compression) filter chain on my default sink (aesthetics, and to overcome ambient noise). This uses two different instances of module-ladspa-sink, so when I fire up Cadmus it works (mostly) but if I toggle NS to Disabled it unloads all module-ladspa-sink instances, including my DRC chain.

Cadmus should be selective about which modules it unloads so as not to bork other pulseaudio configurations and applications.

I've forked and am going to look at resolving it, this issue has been filed for visibility.

[developedby]

This link shows how to. Basically you have to capture the id of the module when loading and then unload only the correct id.

[mainmachine]

Yes! That is exactly where I'm going with this. Take a look at my WIP fork if you're so inclined. :)

[livkx]

@mainmachine Can I invite you to bring your changes to my fork? I'm trying to look after maintenance of this project until (if ever) the original author returns from being MIA. I have the no output/slider fix PR merged in already, and I'm currently working on adding proper config, settings menu & auto on startup support.

[mainmachine]

@livkx Certainly! I have not done much yet, but I will do a PR for the WIP branch I have going. :)

Alternately, you can give me developer access so I can just work directly on a branch in your fork - that would be a lot easier. AFAIK you can control access based on branch, merge permissions, etc. so you could just give me access to the branch I'm working on for now. I am more familiar with doing this on a self-hosted Gitlab instance, but I believe the permissions/access control is basically equivalent.

How would you like to do this?

[livkx]

@mainmachine Great I'm happy to work with you! I've invited you to collaborator access on the repository. Due to all of the code being in one file, I think the best way of doing it would be for us to just work on the develop branch together in order to avoid any merge conflicts :) As long as we both remember to keep our local copies up to date and regularly commit, I think we shouldn't find any major problems.

Perhaps as the project expands we can start moving features into different files so we can do proper feature development branches.

[mainmachine]

@livkx Just switched my origin locally to your fork and pushed the bugfix branch I'd already started. I use the git flow method heavily, and I'm not afraid of merges. :)

I've found it's actually easier to avoid conflicts by working in separate branches, unless the codebase is large enough to prevent folks from working on the same files.

We'll have to figure out how and where to communicate going forward - this page isn't really the right place any more. ;)