Could not find compatible PipeWire

[lucaspar]

EasyEffects Version

7.0.4

What package are you using?

Flatpak (Flathub)

Distribution

Kubuntu 23.04

Describe the bug

Seeing the following message when running Flatpak's Easy Effects:

Could not find compatible PipeWire. It is recommended to install PipeWire 0.3.44 or newer for Easy Effects to work correctly.

More info: PipeWire was found, which is not considered recent enough for Easy Effects. If on Ubuntu or an Ubuntu-based system you may install newer PipeWire from: https://pipewire-debian.github.io You may try PulseEffects which does not require PipeWire. You may dismiss this warning by clicking "OK", please note PipeWire is not tested to work with Easy Effects.

If you believe this message was shown in error, please report it to: https://github.com/wwmm/easyeffects

Expected Behavior

No warning, since PipeWire 0.3.65 is available (>0.3.44 required).

Debug Log

Debug Log

pw-dump succeeded; system likely has PipeWire 0.3.x or later.
You have PipeWire  installed
This is less than PipeWire 0.3.44 recommended to run Easy Effects
(process:2): easyeffects-DEBUG: 18:26:32.971: 	easyeffects.cpp:35	easyeffects version: 7.0.4
(process:2): easyeffects-DEBUG: 18:26:32.971: 	easyeffects.cpp:45	locale directory: /app/share/locale
[ more lines attached ]

easyeffects.debug.log

Additional Information

Installed EasyEffects (most recent atm):

Easy Effects	com.github.wwmm.easyeffects	7.0.4	stable	system

Output of flatpak run, when not in debug mode:

pw-dump succeeded; system likely has PipeWire 0.3.x or later.
You have PipeWire  installed
This is less than PipeWire 0.3.44 recommended to run Easy Effects

Installed PipeWire:

$ pipewire --version
pipewire
Compiled with libpipewire 0.3.65
Linked with libpipewire 0.3.65

[vchernin]

It looks like a bug of the wrapper script used to check the pipewire version. I was planning on getting rid of said script for a while, and replacing it with a better check (see how core version: 0.3.65 is correctly outputted in the app's logs, we should use that instead).

Until that is fixed as a workaround you can do flatpak run --command=easyeffects com.github.wwmm.easyeffects

[lucaspar]

Thanks for the quick reply.

The workaround doesn't show the warning, but it seems I can't close the window and leave EasyEffects running in the background as I used to (even with "Shutdown on window closing" off in the preferences). Any easy way to fix that in the meantime?

[vchernin]

but it seems I can't close the window and leave EasyEffects running in the background as I used to

Can you show logs when trying to disable shutdown on window close (can you try enabling and disabling it)?

G_MESSAGES_DEBUG=easyeffects flatpak run --command=easyeffects com.github.wwmm.easyeffects

You may want to quit easyeffects first with: flatpak run --command=easyeffects com.github.wwmm.easyeffects -q

[lucaspar]

Debug log of

G_MESSAGES_DEBUG=easyeffects flatpak run --command=easyeffects com.github.wwmm.easyeffects

easyeffects.debug.log

• at 19:23:40 I toggle shutdown on window closing ON (it was off), then 2s later I toggle it OFF
• at 19:23:47 I press Ctrl+W, which closes the entire application instead of just the window.

[wwmm]

but it seems I can't close the window and leave EasyEffects running in the background as I used to

You have to pass the command line option --gapplication-service for it to keep running in the background.

[vchernin]

at 19:23:47 I press Ctrl+W, which closes the entire application instead of just the window.

Did you mean Ctrl+Q here? Ctrl+W only closes the window.

I don't see anything obviously wrong with the logs.

Note if you launch from the command line and service mode to work you will want flatpak run --command=easyeffects com.github.wwmm.easyeffects --gapplication-service. Otherwise easyeffects will always close. The desktop file normally launches with that flag.

[lucaspar]

Did you mean Ctrl+Q here? Ctrl+W only closes the window.

But that's what I want - just the window, not the entire app.

I got it now, --gapplication-service was missing - thank you @vchernin and @wwmm

[Digitalone1]

Isn't there a reliable way to check the Pipewire version in the application rather than relying on a script?

[vchernin]

Isn't there a reliable way to check the Pipewire version in the application rather than relying on a script?

There is, you can just do a string comparison of the core version found in pipe_manager.cpp:

https://github.com/wwmm/easyeffects/blob/b8f413d20559c70fb34ce6f45bde06a5f1db5fb2/src/pipe_manager.cpp#L1398

The issue is we then would need to turn the application into one Adwaita status page with the warning. I tried doing it before but since I am not very familiar with gtk I gave up.

Also, there are scenarios where PipeWire is not running or way too old, or say the default metadata is missing. In those situations Easy Effects currently can’t even open, and somehow we should show a status page or something more user friendly than a command line warning. The wrapper script when working as intended can handle the PipeWire missing or too old scenarios. I am not sure how difficult it would be to get Easy Effects (or at least an empty window with the status page) to start without PipeWire working at all.

[Digitalone1]

That is the system Pipewire version. Where is the Flatpak version?

Anyway, I'm afraid a simple comparison is not enough. String versions should be compared to say if one is higher/lower than another and, from my experience, this is very tricky.

We already have utils to show message dialogs and AdwToasts, it's a matter of how to get both strings and evaluate them. Showing an AdwToast in the main window should be easier anyway.

[vchernin]

That is the system Pipewire version. Where is the Flatpak version?

We only need to check the system (daemon) version. The flatpak version (the library) is from the flatpak runtime. We can rely upon the flatpak runtime to provide a functional and reasonably up to date pipewire library. The system pipewire is completely out of flatpak's control so we cannot rely on it working or being there.

Anyway, I'm afraid a simple comparison is not enough. String versions should be compared to say if one is higher/lower than another and, from my experience, this is very tricky.

if (static_cast<std::string>(info->version) >= "0.3.44"){
    util::info("pipewire version matched is new enough");
  }
  else {
    util::warning("version is too old, needs to be 0.3.44 or newer");
    // show status page warning
  }

At least from some testing this was correct enough for me. But I’m still not sure how to deal with pipewire not working at all and still starting some kind of application.

We already have utils to show message dialogs and AdwToasts, it's a matter of how to get both strings and evaluate them. Showing an AdwToast in the main window should be easier anyway.

I don’t think AdwToast makes sense as it’s too easy to miss. A message dialog is better but still, some users might just click through and ignore it. If pipewire is non functional or too old I think we should not let the user use the application at all.

If I have time I will try experimenting with making a different window only with a status page.

[wwmm]

But I’m still not sure how to deal with pipewire not working at all and still starting some kind of application.

That is hard to deal with. Specially if the side effect is the thread freezing waiting for something that will never happen.

[Digitalone1]

At least from some testing this was correct enough for me.

No, string comparison is made character by character, so 0.3.5 > 0.3.44, but you don't expect so.

[Digitalone1]

I don’t think AdwToast makes sense as it’s too easy to miss. A message dialog is better but still, some users might just click through and ignore it. If pipewire is non functional or too old I think we should not let the user use the application at all.

The problem is we already use a message dialog to signal a corrupted preset and, if this preset is autoloaded, a message dialog is shown at the application startup (when the service is started alongside the window opening).

I don't know if bad things happen when we show two message dialogs at the same time. At least this case is correctly handled by AdwToasts with the priority and if you don't want to miss it, just disable the autohiding.

[Digitalone1]

Anyway I'm missing something.

if (static_cast<std::string>(info->version) >= "0.3.44")

We get info->version, but the other string where does it come from? Is it hardcoded in Easyeffects?

In any case, doing this check every tyme the window is shown might not hurt.

[vchernin]

Is it hardcoded in Easyeffects?

Yes.

I don't know if bad things happen when we show two message dialogs at the same time

I think this situation can’t happen. Say if pipewire isn’t available currently the preset code doesn’t end up being used at all right?

[Digitalone1]

Yes.

So for a reliable comparison you need to extract numbers from version strings with regular expressions, then convert them to integer and compare.

I think this situation can’t happen. Say if pipewire isn’t available currently the preset code doesn’t end up being used at all right?

You're right, but if Pipewire version is lower than the recommended one, I suppose the application can start normally and you still want to warn the user.

[Digitalone1]

@vchernin I made this draft to compare version strings: https://jsfiddle.net/dk8Lbsfn/

Basically it returns -1, 0, 1 if a version is lower, equal or higher than another, or an empty string if the comparison fails. It can be converted to C++.

@wwmm what do you think if we make an util for this and show the result of the comparison on the debug console at window startup? Then you can use it to show a warning to the user if needed.

[wwmm]

what do you think if we make an util for this and show the result of the comparison on the debug console at window startup? Then you can use it to show a warning to the user if needed.

I think it is fine to do it.

[Digitalone1]

I'm trying to work on this. Which is the difference between library_version and header_version? I suppose we need to compare the library version, right?

Update: Where is the hardcoded version of Pipewire inside the EE code?

[vchernin]

Which is the difference between library_version and header_version? I suppose we need to compare the library version, right?

library_version is the library linked to at runtime. It can change when users update the runtime, without rebuilding the easyeffects flatpak, since the runtime is supposed to be api compatible. header_version is what was used at build time, and again can change in flatpak, as each time the flatpak is built the runtime may have been updated.

We don't need to check either of them. library_version we know is new enough in the flatpak runtime, and header_version is checked by meson. The problematic version is the pipewire daemon itself which is provided by the distribution and never flatpak.

The only comparison we need to make is the one from above if (static_cast<std::string>(info->version) >= "0.3.44") (but with your corrected string comparison code).

Update: Where is the hardcoded version of Pipewire inside the EE code?

It isn't anywhere in the code right now, it might as well be placed with the new comparison code. 0.3.44 is still the minimum supported version we want to check as far as I know.

[vchernin]

By the way, for testing you might find it useful to build and run older versions of pipewire to confirm (but do not install them to your system). You can build pipewire using meson, and then just run the entire daemon from the build directory with their script without installing it.

[Digitalone1]

@vchernin The only info->version I see is the one in on_core_info inside pipe_manager.cpp that is invoked whenever the core info is updated. So should we make this comparison every time pipewire core is updated? It seems weird to me. Maybe we should save/update it somewhere and compare only when the window is showed.

[vchernin]

It seems weird to me.

Originally I thought we need to do this comparison once at startup of the application. But maybe it is worth doing the comparison every time the window is opened since info->version could possibly change. So I think using on_core-info might make sense. EasyEffects seems to assume PipeWire will keep running without updating or restarting through the lifetime of the application, but obviously it could change at any time.

[wwmm]

EasyEffects seems to assume PipeWire will keep running without updating or restarting through the lifetime of the application, but obviously it could happen.

If pipewire dies or is restarted easyeffects will have to be killed and manually restarted. So there is no need to check this whenever the window is opened.

[Digitalone1]

EasyEffects seems to assume PipeWire will keep running without updating or restarting through the lifetime of the application, but obviously it could happen.

If pipewire dies or is restarted easyeffects will have to be killed and manually restarted. So there is no need to check this whenever the window is opened.

So where do you suggest to check?

[wwmm]

So where do you suggest to check?

The first place that comes to my mind is the end of the callback on_startup https://github.com/wwmm/easyeffects/blob/90f8fb7695f839fb40fc9fbbf650a1b7e6cbc859/src/application.cpp#L53. One of the first things this callback does is initializing PipeManager. So you should have all the information you need there.

[wwmm]

The only comparison we need to make is the one from above if (static_caststd::string(info->version) >= "0.3.44") (but with your corrected string comparison code).

I think we just print but do not save info->version. So for the check to be done outside of on_core_info this variable will have to be saved to a public PipeManager member. Another option is creating the typical getter function for this.

[Digitalone1]

Where to make the comparison has to be decided. Saving the current version into the PM structure seems the better approach.

We should also decide where to declare the minimum pipewire version.

Anyway, I made the util. Tested it inside on_startup:

  // TEST compare_versions
  util::debug("TEST compare_versions");
  util::debug("0.3.44 vs 1.0.0: " + util::compare_versions("0.3.44", "1.0.0"));
  util::debug("1 vs 0.3.44: " + util::compare_versions("1", "0.3.44"));
  util::debug("0.3.44 vs 0.3.5: " + util::compare_versions("0.3.44", "0.3.5"));
  util::debug("0.3.44 vs 0.3: " + util::compare_versions("0.3.44", "0.3"));
  util::debug("0.3.44 vs 0.3.44: " + util::compare_versions("0.3.44", "0.3.44"));
  util::debug("0.3.44 vs 0.11.44: " + util::compare_versions("0.3.44", "0.11.44"));
  util::debug("0.3.44 vs 'not valid': " + util::compare_versions("0.3.44", "not valid"));

The results:

Will make the PR.

[Digitalone1]

Is there a way to use the new util to show a warning when the window is opened? Any suggestion?

At the moment I added a command line warning if the version is lower.