Fedora 35 issues

[vchernin]

I had trouble with Fedora 35, I belive this may be related to this: https://fedoraproject.org/wiki/Changes/WirePlumber It's the only significant change I know has happened to PipeWire in Fedora 35.

All the below is for 35 but not 34:

On this build the enabling switch in the output section is just grayed out :

This picture is on stable (6.1.0 tag):

This is on this PR's build: Enabling the switch on this build reliably causes easyeffects to crash within a second. The only log from doing so is the joyful: Segmentation fault (core dumped)

I think that issue is likely a regression from some other change in master.

Also I found on Fedora 35 I don't think EasyEffects Flatpak even stable is working at all... I think this is not an EasyEffects problem though.

I am curious what happens with the COPR build on 35.

Originally discussed: https://github.com/wwmm/easyeffects/pull/1141#issuecomment-917130265

[Digitalone1]

So Fedora has wireplumber.

If someone wants to test, follow instructions here.

[Digitalone1]

@vchernin can you try to temporarily disable wireplumber and enable the original pipewire-media-session?

[wwmm]

The app switch is the only thing we do through the session manager. So I agree it is suspicious to have problems after moving to wireplumber.

[vchernin]

I can confirm switching to pipewire-media-session with sudo dnf swap wireplumber pipewire-media-session and reboot fixes the issue and EasyEffects works normally on Fedora 35.

[wwmm]

Well... I imagine that if they are switching to wireplumber is because it is supposed to be a drop-in replacement to the built-in session manager. If that is not happening I think the issue is on the wireplumber side.

[wwmm]

Unless that when wireplumber is running the metadata has a name different than default. That would be a problem as it can be seen at https://github.com/wwmm/easyeffects/blob/e293cf5cc3c8e4b52c6ce20397d7c0855246cb27/src/pipe_manager.cpp#L968. @vchernin run easyeffects in debug mode. At least without wireplumber I see lines like these

pipe_manager: found metadata: settings
pipe_manager: found metadata: default
pipe_manager: found metadata: route-settings

Does the line with the name "default" changes to something else? Our interaction with the session manager is essentially some calls to pw_metadata_set_property. So the metadata object can not be null. But it will be if no metadata named "default" is available. The other types of metadata serve other purposes and are useless for us. So we have to know the right name.

[Digitalone1]

Anyway wireplumber is available on Arch also. If it's not working with it, we have to specify pipewire-media-session as explicit dependency.

[vchernin]

easyeffects.log

[vchernin]

Also I can confirm the issue on Arch, after installing wireplumber and and enabling it per this.

[wwmm]

Curiosity got the best of me and I decided to investigate. It turns out the problem is not where I thought it would be. Removing this line makes things work with WirePlumber https://github.com/wwmm/easyeffects/blob/e293cf5cc3c8e4b52c6ce20397d7c0855246cb27/src/effects_base_ui.cpp#L672. Honestly I do not remember since when this call is done. @Digitalone1 is this a recent change? As the function application_info_update is the callback of the signal emitted by holder->info_updated.emit(); and inside the callback we call pointer_connection_enable->block(); some kind of thread locking may be happening. But I wonder why only when WirePlumber is used... Strange...

[Digitalone1]

Try also adding and removing from the blocklist.

Anyway that call was useful to update the app info UI on switch and blocklist changes. Sometimes it was not updating.

I don't think it's an issue related to pointer_connection_enable because we change the switch only between the connection block/unblock.

https://github.com/wwmm/easyeffects/blob/e293cf5cc3c8e4b52c6ce20397d7c0855246cb27/src/effects_base_ui.cpp#L739

[Digitalone1]

I'm making some tests commenting the info_updated.emit(). If the app is blocklisted while it's not enabled, the enable switch remains sensitive.

Besides, if the app is not enabled from the start (because of Process all Output not enabled), when you add and remove it from the blocklist sometimes the app_info_ui is empty.

[wwmm]

Oh! I see. But maybe there is a better way to achieve the same results. I am not sure we should be calling the connection block function inside the slot that is being handled by the connection we want to block.

I did some tests with Pavucontrol. If we enable and disable the application there the switch changes in our window with no crash. It is only when we change its state by clicking on our switch that the crash happens.

[wwmm]

I did more tests. The real source of the problem is calling https://github.com/wwmm/easyeffects/blob/e293cf5cc3c8e4b52c6ce20397d7c0855246cb27/src/effects_base_ui.cpp#L739. The rest is fine. I can see the call to set_active inside the switch callback being a problem. I think that there is a high chance pointer_connection_enable->block(); is not avoiding it because the call happened inside the state changed slot.

[Digitalone1]

The switch changes because pipewire triggers some change and on_app_changed is called to update the ui. Unfortunately this is not happening when the blocklist checkbutton is toggled while the app is disabled.

I'm also testing and find out a bad bug. If show blocklisted apps is untoggled, the app info ui might not work in some situations because the item is not updated. I forgot to update the items of all_players_model inside on_app_changed, I only updated the players_model.

Now I fixed this, but can you suggest me how to update the enable switch on the checkbutton toggle?

For the connection block, all these block/unblock calls are inside application_info_update, so do you mean they have to moved outside?

[wwmm]

For the connection block, all these block/unblock calls are inside application_info_update, so do you mean they have to moved outside?

I do not think we can. We have to do these operations inside the info_updated signal. The real issue is the amount of complexity we are having to add to keep the blocklist interface consistent. Calling enable->set_active inside the info_update signal slot is totally fine as long as we do not do that inside the switch callback. What is totally understandable. It is a miracle the same problem did not happen with the other session manager.

[wwmm]

I've found a way to "fool" gtk XD. Replace the emit call that is inside the switch by

Glib::signal_idle().connect_once([=] { holder->info_updated.emit(); });

This way the emit is not done inside the switch callback. It will be scheduled to run the next time gtk's main loop is idle.

[wwmm]

@Digitalone1 as you are already preparing some changes it may be more productive to add this in your pull request

[wwmm]

This way the emit is not done inside the switch callback. It will be scheduled to run the next time gtk's main loop is idle.

I forgot to say that this fixed the problem with wireplumber. At least on my computer.

[Digitalone1]

If the problem is the holder->info_updated.emit() inside the switch callback, I can delete it since it's not really necessary because when a stream is connected/disconnected pipewire triggers a change and the ui is updated.

We need it when an application is added/removed from the blocklist to update the sensitive property of the enable switch.

Another issue is that on_app_changed is called too many times in a short interval by pipewire. We don't need all those calls, they may trigger race conditions. I wonder if there's a way to skip some calls if another one is already scheduled.

[wwmm]

If the problem is the holder->info_updated.emit() inside the switch callback

Almost that. This signal can be emitted there. The problem was that its slot called enable->set_active. And that call inside its own callback is usually not a good idea. And in this case it was the reason for the crash. Scheduling the info_updated emit for when gtk is idle fixed the problem. But if we do not need to emit this signal there it is better.

[wwmm]

We don't need all those calls, they may trigger race conditions.

I agree that we do not need all these calls. But I am not sure about the race conditions. The signals are scheduled by Glib::signal_idle() for the next moment gtk's main loop is idle. While it is true that there is a high amount of calls gtk batches all of them in a way that increases performance and they are all serialized in gtk's main thread. So there should not be race between threads because everything scheduled by Glib::signal_idle() runs in the main thread.

[wwmm]

Another point is that in service mode almost nothing is done when on_app_changed is called. The overhead is more when the window is opened. At least I have it closed most of the time.

[Digitalone1]

I added a scheduled_update bool flag in NodeInfoHolder and made the following code:

      try {
        item->info = pm->node_map.at(id);

        if (!item->scheduled_update) {
          item->scheduled_update = true;

          Glib::signal_idle().connect_once([=] { item->info_updated.emit(); });

          util::debug("-- update scheduled");
        } else {
          util::debug("-- update skipped");
        }
      } catch (...) {
      }

scheduled_update is made false at the finish of application_info_update callback.

Look at the log

(easyeffects:14616): easyeffects-DEBUG: 17:29:24.573: pipe_manager: new metadata property: 120, target.node, Spa:Id, 90
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.575: -- update scheduled
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.575: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.575: -- app info ui updated
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.578: -- update scheduled
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.578: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.578: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.578: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.578: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.578: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.578: -- app info ui updated
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.579: -- update scheduled
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.579: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.579: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.579: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.579: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.579: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.579: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.579: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.579: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.580: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.580: pipe_manager: io.github.celluloid_player.Celluloid port 85 is connected to easyeffects_sink port 80
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.580: pipe_manager: io.github.celluloid_player.Celluloid port 112 is connected to easyeffects_sink port 59
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.580: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.580: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.580: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.580: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.580: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.580: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.580: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.584: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.584: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.584: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.584: -- app info ui updated
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.636: -- update scheduled
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.637: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.640: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.640: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.640: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.640: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.640: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.640: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.640: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.640: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.641: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.641: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.641: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.641: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.641: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.642: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.643: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.644: -- update skipped
(easyeffects:14616): easyeffects-DEBUG: 17:29:24.647: -- app info ui updated

More than 40 calls in less than 100 ms. With this flag we only did 4 updates.

I think this is a good approach. What do you think? Any downside I might miss?

[wwmm]

Any downside I might miss?

So far I did not see one. In PulseEffects the stream info was used to decide if our pipeline should be active or not. But in PipeWire we have the link info for that. So in theory reducing the actions taken when we receive node info updates should not cause problems.

[lakotamm]

I just installed the latest Easyeffects Flatpak 6.1.1 on Fedora 35 Silverblue (19th Sept build). I can confirm that Firefox output is not processed and enabling the button results in a segfault.

104.447362] easyeffects[2126]: segfault at 7ffcc80f9f68 ip 00007f3d718d5741 sp 00007ffcc80f9f10 error 6 in libc-2.31.so[7f3d718a8000+150000] [ 104.447371] Code: 00 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 55 49 89 f3 48 89 e5 41 57 41 56 41 55 41 54 49 89 fc 48 89 d7 53 48 81 ec 28 01 00 00 <48> 89 b5 08 ff ff ff 0f b6 77 0c 48 89 95 38 ff ff ff 64 48 8b 04 [ 385.899718] easyeffects[6835]: segfault at 7ffd4f741ff8 ip 00007f48cda5c6f8 sp 00007ffd4f742000 error 6 in libc-2.31.so[7f48cda34000+150000] [ 385.899728] Code: 00 00 48 8b 04 cf 48 f7 f6 48 83 e9 01 73 f3 48 89 d0 c3 0f 1f 80 00 00 00 00 31 d2 eb d6 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 <41> 57 49 89 f7 41 56 41 55 49 89 d5 41 54 53 4c 89 c3 48 83 ec 58 [ 707.389827] easyeffects[7045]: segfault at 7fff34d41fe8 ip 00007f720f852d82 sp 00007fff34d41ff0 error 6 in libc-2.31.so[7f720f825000+150000] [ 707.389836] Code: 95 18 ff ff ff e9 74 fa ff ff 66 0f 1f 44 00 00 4c 8d 7d a0 48 8d 8d 5c ff ff ff be 02 00 00 00 48 8d 95 68 ff ff ff 4c 89 ff 19 bc ff ff 89 c1 48 89 85 78 ff ff ff 49 89 c5 c1 e1 06 44 8d

[Digitalone1]

The changes in the last merge request should fix this issue.

[wwmm]

104.447362] easyeffects[2126]: segfault at 7ffcc80f9f68 ip 00007f3d718d5741 sp 00007ffcc80f9f10 error 6 in libc-2.31.so[7f3d718a8000+150000]

@lakotamm the segmentation fault you see has another source that has yet to be found. The crash related to wireplumber that is being discussed here does not happen in functions related to libc. It is better to open a new issue for your case. In the mean time check if you did any update recently and if you rebooted your computer. Sometimes weird problems with no clear source are fixed by rebooting the computer after upgrading the audio server.

[lakotamm]

@lakotamm the segmentation fault you see has another source that has yet to be found. The crash related to wireplumber that is being discussed here does not happen in functions related to libc. It is better to open a new issue for your case. In the mean time check if you did any update recently and if you rebooted your computer. Sometimes weird problems with no clear source are fixed by rebooting the computer after upgrading the audio server.

Thanks for your reply. I will give it another try in the evening. However, the fix made by @Digitalone1 seems to resolve also this issue. Should I do the test again with the official version 6.1.1 and report the issue?

[wwmm]

Should I do the test again with the official version 6.1.1 and report the issue?

If the segmentation fault is gone no need to report anything. Only if it comes back somehow.

[lakotamm]

I built a flatpak based on the latest master branch (after the merge). The application no longer crashes when the button for enabling processing is turned "on" . However, audio processing for Firefox is still inactive - there is no change in audio, and there is also no visual indication of audio playing in the top bar . Also, the moment I pause playing audio in firefox, the button goes back to "off" and stays there until I trigger it again.

I made a log, but I cannot really find there anything useful. easyeffects.log

(Fedora 35 Silverblue)

[Digitalone1]

Maybe the function for linking nodes with pipewire-media-session is now working with wireplumber.

I don't know pipewire in dept, but that function was specific for pipewire-media-session and only used for stereo downmixing.

@wwmm what do you think?

[wwmm]

wwmm what do you think?

We use the session manager to move the applications to our virtual devices. The function used is supported by both sessions managers. So that is not the problem. The only other thing I can think of now is

pipe_manager: compiled with pipewire: 0.3.31
pipe_manager: linked to pipewire: 0.3.31
pipe_manager: core version: 0.3.34

I think that the core version is the one detected at runtime. The first two are the ones available when EasyEffects was compiled. Maybe that is the key to the problem. Here on Arch Linux everything is on 0.3.35.

[Digitalone1]

Here on Arch Linux everything is on 0.3.35.

I'm on 0.3.36.

[vchernin]

Relevant Fedora 35 update links:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-57267aa61a

https://bodhi.fedoraproject.org/updates/FEDORA-2021-6bd86ba1c3

Neither 0.3.35 or 3.3.36 is available in Fedora 35 stable yet. But if you have a dnf based install you can quickly test that.

[wwmm]

I'm on 0.3.36.

For some reason the Brazilian repositories do not have this version yet. From time to time they have problems. I will see if there is another url with the latest packages.

[wwmm]

That is weird. I actually already have PipeWire 0.3.36. But even after recompiling EasyEffects PipeWire is still reporting 0.3.35 to us. What?!?

[wwmm]

pipewire --version
pipewire
Compiled with libpipewire 0.3.35
Linked with libpipewire 0.3.35

Well... I think they forgot to update the tag when releasing 0.3.36. Or the package maintainer did something wrong... In any case let's go back to the topic. I am doing many tests with Firefox and so far no problems. The audio effects are working.

[lakotamm]

Relevant Fedora 35 update links:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-57267aa61a

https://bodhi.fedoraproject.org/updates/FEDORA-2021-6bd86ba1c3

Neither 0.3.35 or 3.3.36 is available in Fedora 35 stable yet. But if you have a dnf based install you can quickly test that.

I guess I could try to rebase to the testing branch, but I do not know whether the packages are updated in the testing branch. rpm-ostree rebase fedora/35/x86_64/testing/silverblue

pipe_manager: compiled with pipewire: 0.3.31 pipe_manager: linked to pipewire: 0.3.31 pipe_manager: core version: 0.3.34

I think that the core version is the one detected at runtime. The first two are the ones available when EasyEffects was compiled. Maybe that is the key to the problem. Here on Arch Linux everything is on `0.3.35`.

So if I understand correctly, even though I have 0.3.34, the flatpak was build and linked with 0.3.31. Is there any easy way of building with a newer version?

pipewire --version pipewire Compiled with libpipewire 0.3.34 Linked with libpipewire 0.3.34

[vchernin]

I have no idea what's going on with Arch. Assuming the commits are correct the packaging process looks normal.

0.3.36

0.3.35

I will test my Fedora 35 vm later when I'm at my computer and report back

[vchernin]

So if I understand correctly, even though I have 0.3.34, the flatpak was build and linked with 0.3.31. Is there any easy way of building with a newer version?

You can update the PipeWire version in the Flatpak manifest. That will update the version used at build time (it's incorrectly reported in EasyEffects though IIRC). I kinda doubt that will help but it's worth a shot. Or maybe one of the Arch users could try the stable Flatpak (it's not updated to 6.1.2 quite yet).

But the server PipeWire version cannot be updated through Flatpak. I have no idea how to test dnf testing advisories on Silverblue, I've never tried figuring that out.

[vchernin]

I tested 6.1.2 Flatpak (releasing now) on Fedora 34 Workstation with 0.3.36 server and it's still the same behaviour.

I will try building EasyEffects with newer PipeWire.

[vchernin]

Ok building EasyEffects Flatpak with 0.3.36 didn't do anything either.

[wwmm]

Ok building EasyEffects Flatpak with 0.3.36 didn't do anything either.

I wonder why. Could it be the wireplumber version being used? Here on Arch I have 0.4.2.

[vchernin]

35 is on 0.4.1. It seems 0.4.2 has been caught by the 35 freeze...

[vchernin]

Now that wireplumber 0.4.2 is installed on 35 it still doesn't work :(

[Digitalone1]

I'm trying to test wireplumber, but I can't disable pipewire-media-session. Whenever I disable it, it stays enabled. If I try to uninstall it, I can't do it without uninstalling also pipewire-pulse.

pipewire-media-session on Arch is an hard dependency and I can't disable it. On Fedora instead packagers replaced it with wireplumber.

[vchernin]

@wwmm you were testing on Arch too right? Is it possible you never actually fully disabled pipewire-media-session and were using that instead of wireplumber?

[vchernin]

There's probably some pacman command to remove pipewire-media-session safely, but I wouldn't know.

[Digitalone1]

@vchernin No, If I do it I have to remove pipewire-alsa, pipewire-jack and pipewire-pulse. Without them nothing will work.

https://archlinux.org/packages/extra/x86_64/pipewire-media-session/

Try to install pipewire-media-session alongside wireplumber on Fedora and see if it's working. At least on Arch it's intended to be installed with pipewire-media-session because the package does not report a conflict.

https://archlinux.org/packages/community/x86_64/wireplumber/