Automatically disable any audio source for effects that is not matched by regex

[SnoutBug]

I would like to see a feature to automatically filter any audio source that is not matched by a regex that I specify. Usually I only want to enable noise suppression for meetings or calls, but not for myself, but for the participants, ie in the output panel. The current system allows me to exclude apps, which I don't want, since most of my calls are inside Firefox. So when I exclude Firefox from the effects I don't get any noise cancellation and when I don't, I have to uncheck every unwanted source manually, which is rather tedious. Additionally, all audio sources are enabled by default, which means that the noise cancelling is also applied to games or other media, which I then have to exclude manually again. Disabling the setting: "Process All Output Streams" is also not very helpful to me, since all enabled sources will be reset back to disabled once I restart the app.

[wwmm]

Disabling the setting: "Process All Output Streams" is also not very helpful to me, since all enabled sources will be reset back to disabled once I restart the app.

Not necessarily. WirePlumber will remember the associations made when toggling EasyEffects Enable checkbox. The problem with this approach is that it may reset this association whenever it considers it has to do so. We have no control over what WirePlumber does.

I think that the only appropriate way to support regex would be to somehow allow them to be used in our blocklist. And in a way that a regex that negates everything except the given word would have priority over the other entries in the blocklist. The thing is I am not that well versed in regex. What do you think @Digitalone1 ?

[wwmm]

I would like to see a feature to automatically filter any audio source that is not matched by a regex that I specify.

Just have in mind that the blocking is done for the whole app. So you can't selectively block Firefox streams for example. Either Firefox is blocked or it isn't independently of whether regex are supported or not.

[wwmm]

Just have in mind that the blocking is done for the whole app. So you can't selectively block Firefox streams for example. Either Firefox is blocked or it isn't independently of whether regex are supported or not.

Some apps define an unique application_id for their streams. In these cases it is possible to not block the whole app by targeting only the application_id of the undesired stream instead os using the app node name. Unfortunately almost no audio app sets an unique application_id for each stream. So in practice blocking just specific streams is not very viable.

[Digitalone1]

EE can block a specific application by its name, but not specific streams of the same application. I understand the use case of @SnoutBug, but this is so specific that should be implemented by the app itself (I suppose it's Discord?).

It's too much for us considering that in the current state we already had issues blocking by name. See pavucontrol for languages other than English (if I remember correctly, we had to use a workaround for that). Starting to block also specific streams of a single application would lead to other issues.

The thing is I am not that well versed in regex. What do you think @Digitalone1 ?

I don't think it's a good idea. Regex are more powerful in string management, but also less efficient in system resources. Besides they can be also dangerous because a user can define a very complex expression that puts very high load on the CPU.

[wwmm]

It's too much for us considering that in the current state we already had issues blocking by name. See pavucontrol for languages other than English (if I remember correctly, we had to use a workaround for that). Starting to block also specific streams of a single application would lead to other issues.

In Pavucontrol we solved by blocking the application_id. But this only worked because Pavucontrol is among the few if not the only audio app that sets unique application_id for its streams. As it sets the same unique id for all its streams and this does not depend on translations we were able to blocklist it.

OBS on the other hand does not set unique id for its streams and as a result the ignore monitor streams workaround was required. Per stream blocking is annoying because in general streams do not provide enough information for this to be done in a generic and reliable way.

Besides they can be also dangerous because a user can define a very complex expression that puts very high load on the CPU.

Oh... I did not even think about this.