So we can conclude installing pulseeffects was a user decision, so the user should keep up with the dependency changes of his applications.
It has been mentioned in a lot of recent posts
and it has also been mentioned that Manjaro also now has
pulseffects-legacy in community repository that still depends on PulseAudio
Now I understand - I have edited my comment to reflect this POV - thank you and accept my apology for not understanding immediately the POV.
The developer of Pulseeffects had intended to make this change for a long time
[Feature Request] Adding support to Pipewire? · Issue #397 · wwmm/pulseeffects · GitHub
But IMO there should have been plenty of time to change the package name and description to reflect the change of audio server
Why would the package name require changes, if upstream has not changed the software name?
And the package description reads:
Which, to me, is a clear indication, that it’s for Pipewire.
The description was not changed in the first version of Pulseeffects requiring Pipewire
My question would be why would the developer not change the name?
That’s an issue the Arch package maintainer would know about.
Again, a question for the developer. It’s not something Manjaro has any control over.
I am not sure if I understand the context correctly but pipewire is a dependancy for kwin.
Thank you for that info. I have just checked for pulseaudio related packages - not the window manager - and frankly - I didn’t expect a window manager to be depending on a specific type of sound library
I am not a KDE user so the dependencies of KDE is not familiar to me - but I can confirm this from a quick view on kwin dependencies.
When kwin has a hard dependency on pipewire then this is not a decision taken by Manjaro but a choice made by upstream KDE.
Changes made by upstream KDE is their choice and not a Manjaro choice - Manjaro just takes the fall.
And Firefox has as a dependency pulseaudio. I have no understanding of sound system at all, but to me it looks like both solutions: pulseaudio and pipewire should not contradict or conflict with each other.
I have explicitly - purposely - replaced pulseaudio with pipewire for testing purpose and I have no issues with Firefox.
I am planning to make a test install of KDE to see if I can replicate anything …
Found this on the Arch BBS
And from that the following is fun to read
I didn’t expect a window manager to be depending on a specific type of sound library
KWin depends on Pipewire not for the sound part but for the screen casting part. Pipewire (+ xdg-desktop-portal) is the standard way to go about screen casting on Wayland and pretty much all the compositors depend on Pipewire because of that.
ahh - so this is wayland related?
I have seen topic on screen recording working badly on KDE - is this related?
If it is wayland related - there is a lot more sense to these issues.
As far as I understand kwin has become dependent on pipewire in order to ensure there will be screencasting working in Wayland session because without pipewire it’s impossible.
I guess there’s some code in kwin now which relies on a fact that pipewire is up and running.
For what it’s worth, gnome-shell also depends on pipewire.
I don’t think so, the pain point with Wayland screen recording is lacking application support.
All the wayland compositors do (that can do screencasting, anyways).
The dependency of compositors on Pipewire isn’t the problem, it’s been a hard dependency of KWin for a while IIRC. Pipewire on its own also doesn’t replace other audio servers - with
pipewire-jack you can replace pulseaudio and jack with implementations going through pipewire.
The problem is caused by the latest version of pulseeffects having a dependency on
pipewire-pulse specifically, and updating appears to have removed a bunch of packages depending on pipewire. I don’t know why exactly that is, installing pulseeffects on my system right now wouldn’t remove any of them; maybe the update messed it up somehow.
What affected people need to do is re-install those packages themselves, which for example plasma-pa (Volume control of Plasma) is part of.
Optionally they can also revert to manjaro-pulseaudio and use pulseeffects-legacy, if Pipewire doesn’t completely work for them.
Yes sorry, this was what I was going for. My point was that it’s not just kde or just wayland, it’s more that that. Even apps like chrome/chromium is adding support for screen sharing though pipewire, so it’s looking like it’ll become something of a standard going forwards (kinda). It was mostly aimed towards @linux-aarhus who didn’t seem familiar with what it was.
Regarding what kind of decision the Manjaro Team may have made, it is crystal clear to me that the replacement of “pulseaudio” by “pipewire” occurs if the “pulseeffects” package is installed. So, for me, it is not a Manjaro Team decision.
Just for clarify, in other posts of mine I made it clear that…
It would also be nice to hear them (Manjaro Team)
… and that…
As I said, “pipewire” SEEMS to be the standard for Manjaro now.
I ask you to observe this information…
… and this information…
… and finally, I make the following considerations…
I use Manjaro KDE and according to some informations KDE have dependencies in relation to “pipewire” and we also have applications that depends on “pulseaudio”. There is still information that pulseaudio and the pipewire should not contradict or conflict with each other.
QUESTION: What do you recommend for Manjaro KDE users? Install “pipewire”? Install “pulseaudio”? Install “pipewire” and “pulseaudio”?
NOTE: In my particular case, I really don’t mind using any of them (“pipewire” or “pulseaudio”) … But, I would appreciate very much know what you recommend/guide to we have the best possible experience with Manjaro KDE.
There is several pacakges will let you configure settings for sound - also on KDE.
Although the name of the applications in question are labelled as PulseAudio the work fine - at the moment - with pipewire as well also on KDE.