Suggestion: PulseEffects PipeWire-supporting version could use a fork and rename #874
Comments
No problems. I thought a lot about this when I started the port. The thing is I've got used to the current name. And having "Pipe" replacing "Pulse" seemed a little weird.
Renaming would help with that. But package maintainers can help too by forcing a dependency on PipeWire for versions equal or above
This could potentially require more time than I currently have because people will think that both projects will be developed. I do not intend to touch on our Pulseaudio legacy branch unless it stops running for some reason.
This is really hard to do. PipeWire and Pulseaudio do things in a totally different way. Creating a wrapper that allows to use both would take a lot of work. It just does not seem worth the effort. In case you are curious you can take a look at the files https://github.com/wwmm/pulseeffects/blob/master/src/pipe_manager.cpp and https://github.com/wwmm/pulseeffects/blob/pulseaudio-legacy/src/pulse_manager.cpp |
I see what you're saying. However, as a relatively short-term neutral third party, it seems to me to be more weird to stay as "Pulse" which explicitly refers to a particular now-unsupported audio system.
I don't see how that would help users find the latest version that supports PulseAudio. Maybe I'm not savvy enough with package managers, but I'm personally not sure how to get the exact last version of a package from before a particular version number. I just figured it out with the Arch wiki, but I'm not sure if that kind of solution works well for many users. Maybe package maintainers will figure out a clever solution, where they can explain it, but that seems like a messy situation. I'm imagining multiple packages with "pulseeffects" in their names, and if the user chooses the wrong one by version number, they won't know why it's not working. Of course it wouldn't be your fault, but situations like this may come back as issue tickets in the future.
I'm sure users would understand if there's a simple message indicating that development of "PulseEffects" has ceased in favor of "PipeWireEffects". It does seem to me that explaining whether, how, and why "PulseEffects" no longer supports "PulseAudio" has potential to consume more time in total than a rename to "PipeWireEffects".
I thought that might be the case. I forfeit that alternative suggestion. This all being said, I am still only offering my perspective, and I respect your choices for your own project at a rate of 100%. |
Usually the repository will have only one version. I believe that is already the case in most distributions. I know it isn't in Gentoo. But Gentoo users are supposed to know this kind of thing. But Arch Linux for example has only one PulseEffects version in the stable repository. So getting the latest available isn't that hard if you know the package name. If package management is done right a user with Pulseaudio installed shouldn't even be allowed to install a PulseEffects package that works only with PipeWire. The same holds for the other way around. They should not allow the user to install a package that only works with Pulseaudio in a system that does not have Pulseaudio and PipeWire compatibility layer is not installed. Avoiding this is the package manager job. And they will have to do that for any other software using PipeWire native API.
It could be done. I had understood |
|
Erm… Effectspipe? I'll see myself out. Seriously though, I think a name change would make sense, especially from a package maintenance POV. No ambiguity which package to install, no need to look at the version. Just my 2 cents… |
|
A change could be done, but it's not really necessary. Talking about Arch, newer versions will continue to stay on upstream and PulseEffects Legacy could be provided on AUR. The problem is that PulseEffects 4.8.4 isn't released yet on Arch and package maintainers haven't done nothing to prevent PulseEffects stable release to install with Pipewire, breaking all system audio. But this is not a PulseEffects fault. The only thing that could be done is a big statement on github readme saying newer versions are for Pipewire and if you want to stay on Pulse, pick the 4.8.4. I made a custom package on 4.8.4 and will remain on it until it works and will make the switch when Pipewire will be really mature to be used daily. |
In this hypothetical situation, I am imagining it would only mean that temporarily, until the message that development of "PulseEffects" has ceased in favor of "PipeWireEffects" was implemented. Then the separate "PulseEffects" package and source would be readily available for someone else who's interested and dedicated to easily take over. |
|
Does github has some kind of poll mechanism? If most people feel like changing names is better we can do it. It is not a big deal. But I think that finding a good name will be more challenging than the decision of changing it XD |
|
It seems like there's a poll bot on the marketplace: How about PipeFx? |
|
Here's an idea of how a poll can be done right here. DanMan's post above is option 1: PipeFx. Use the "thumbs up" reaction on that post to vote for it. My post here is option 2: PipeWireEffects. Use the "thumbs up" reaction to vote for it. Further posts below can contain further options. I like "PipeWireEffects" because it's crystal clear, discoverable, and matches the format established by PulseEffects. @wwmm Feel free to decide an end date for this ad-hoc poll and/or an alternative polling method. |
|
Hm, I am wondering what to do with packaging of PulseEffects? If update the package to 5.0, then most users won't be able to use it because they use Pulseaudio, if to not update, users of PipeWire won't be able to use it. I thought to make a separate package pulseeffects-pipewire which would conflict with pulseeffects-pulseaudio. PulseEffects is a well-known name... |
Maybe make a separate branch as a branch with python-based version existed? And make new tags 4.x in case of small fixes like fixing buildability with new compilers etc. |
That has been already done. |
I see no problems in doing that. I do not remember the details now but in the past I saw package names like |
It is another reason why I am not into the idea of changing the name. It made sense in the early days to make it easier for people to know the project existed and what was its purpose. But now the situation is different. People are more likely to ask if PulseEffects works on PipeWire than "which effects tool is available for PipeWire?". |
|
I think it's more likely for people to ask if there's a PipeWire equivalent. It wouldn't make sense for "PulseEffects" to work on PipeWire. From how it looks to an outsider, PulseEffects would be for PulseAudio and something else would be for PipeWire. It says "Pulse" in the name. |
|
That is debatable. Once PipeWire is polished to the point where any Pulseaudio application just works on it many users won't even notice Pulseaudio was replaced by it. |
|
And it seems that the next PipeWire release will already be able to run the older PulseEffects versions through its Pulseaudio compatibility layer. |
Well, maybe it was worth to wait that version rather than changing to Pipewire. All that effort could be spent on something else, maybe completing the port to rust you began in the last summer or starting the port to gtk4. |
Not really. PulseEffects situation is not the same as let's say mpv or Firefox. These two don't care if other audio applications move from Pulseaudio API to PipeWire's. But a manager like PulseEffects does. The compatibility layer does not make any PipeWire node visible to the Pulseaudio API. |
|
The advantage of moving to PipeWire's API is that we can manage anything it exposes. If we stay on Pulseaudio API we will see only Pulseaudio applications. They are the majority now. But it won't be like this forever. |
I gave up on that. No idea if I will ever try again. The reason is that we depend too much on a few C libraries. So our fate would also depend too much on their wrappers quality. It did not take long for functions not available in the Rust wrappers to be needed in my attempt to do the port. |
That will be a tough one. And I can't even start it right now. Once the move to PipeWire was finished I started thinking about this. The first blocker is no |
But will be like this in the following 2-3 years. I wonder why I should write a new audio stack for my app if the existing pulse one it's working with Pipewire compatibility layer. Pulseaudio is very stable while Pipewire is not mature yet with some big issues: latency problems stated also here and switch on connect not working, I tried to play mpv on hdmi audio output and there was no easy way to do it during reproduction (on Pulse I don't have to do nothing, just connect the cable and the switch is automatic). I think a few applications will start to support it directly only in the next 2-3 years while others will remain on Pulse. |
Probably. And it is totally fine to do that. And these people will still have PulseEffects. The legacy branch is not going to disappear. Even the Python branch is still there for anyone that needs it for whatever reason. People willing to use PipeWire's native API that were in the cold. |
It is not the same situation but something like that happened in Pulseaudio's early days. The compatibility for ALSA applications was there. Still people moved to Pulseaudio. It will depend on how well the compatibility layer works and on how much effort will be put in making PipeWire the default. In the past Pulseaudio was forced as default too soon... And the ALSA compatibility layer probably had its limitations. At that time I refused to have Pulseaudio on my machines so I do not remember. |
Here's a user's perspective: Last week, I updated "PulseEffects", which contains the string "Pulse", and suddenly it did not support the audio system that's identified by the string "Pulse", named with the full string "PulseAudio". Instead, it supported a different audio system which I did not have installed. This caused PulseEffects to stop working on my computer. This is a real event that happened to a real user of the software. For context, though, I was specifically using the package I feel lucky that I had recently visited the github issues section here and discovered that a branch to support "PipeWire", a new audio system I had never heard of, was in the works, and lucky that I could imagine that this branch had been merged into the master branch, so I could figure out what went wrong. I didn't know where to go other than to install the If I hadn't visited the github issues section here to report the issue with the missing bars, I'm sure I would have had a more difficult time figuring out what was wrong with PulseEffects. I'm almost certain I would never have thought of searching for and installing a package named Not only that, but searching my package manager for This is why I've come to believe it is important to have a separate package with a separate name like "PipeWireEffects" for the audio system identified by the string "PipeWire", and reserve "PulseEffects" for the audio system identified by the string "PulseAudio". Again, this is only a suggestion and a user's perspective. I'm still behind your decisions for your own software 100%. Thank you for writing and maintaining this awesome software. |
|
@AlexFolland This is an Arch Linux issue. I love Arch, but some decision are very disappointing. I don't know if they chose to switch to Pipewire or Pipewire forced to conflict with Pulseaudio, but they didn't do nothing to stop Pipewire upgraded when PulseEffects is installed. That's why the issue came up. Then, PulseEffects 4.8.4 came up a month ago and the maintainer didn't upgrade even if the previous version had some issues with locale fixed in the newer release. I think that if you don't want or don't have the time to maintain a package, should leave the work to other active users. And maybe the whole distribution should have a little care about stability. I know Arch is not Debian, but I need a working system now, not in the next years when Pipewire will be completely stable. If you want a stable PulseEffects version for plain Pulseaudio, install the PKGBUILD on my github repository. |
|
@AlexFolland I agree that what you describe is not nice to the end user. But I disagree that the proper solution is changing the upstream name. Almost everything you said can be fixed with proper distributions package management. When the Linux community moved from ALSA to Pulseaudio applications did not have to change name because the people maintaining the packages set the dependencies and the package names right. When Firefox decided to support only Pulseaudio I did not have any of these problems. "firefox-pulse" was only installed if Pulseaudio was there for it. Even the case about being easier to find out new applications searching for |
|
@AlexFolland I don't think you understand the nature of this problem. Pipewire in it's current state does not work on may systems, therefore i would like to use PULSEeffects with PULSEaudio. This package does not exist. The packagers for my system have not created a version of this package because no-one in their right mind would think the PulseEffects would stop supporting pulse. The reason I would like to use use pulse is that since upgrading yesterday my system's audio:
Yes but PulseAudio was not just called ALSA, was it? The original firefox was not ALSAfirefox. That is why they did not have to change name.
So they did have to change name then?
WORKS ON MY MACHINE™. It only worked because firefox was, and I can not stress this enough, not called ALSAfirefox to begin with. |
But I am also hesitant because not using GStreamer has disadvantages too. Consider the whole process done in porting the application to PipeWire. The effects pipeline had almost no change. We just used it because it was implemented in GStreamer and not in an API that was Pulseaudio only(there isn't one, this is just an example). The same is true the other way around. If I add a new plugin to the PipeWire branch we can just backport it to the legacy branch with minimal or no work. So even if I had the time to rewrite the processing chain without GStreamer I do not think it would be good to follow this path while the Pulseaudio branch is maintained. |
|
@wwmm You do not deserve abuse. I'm sorry someone came by here and sent it to you. Thanks for your project. By sharing my perspective, I never meant for abuse to come your way from somebody else. |
|
I know that was not your intention @AlexFolland :-) |
|
As a common user I agree with @AlexFolland in dropping "Pulse" from the name and putting "Pipe" somewhere. It has nothing to do with Pulse anymore and it is thus misleading for people that aren't closely following the development of the project. I'm putting this here to show my point of view as well, I wish you guys good luck with the development. |
|
If a name change ever happens in the future you can be sure I am not going to add "pipe" to it... The most that can happen is a server neutral name... |
|
Here are some (potentially) server-neutral names.
|
Hahaha XD That is not my problem with it. For some reason I think it is ridiculous to have it in the name XD. To tell the truth I also do not like the name PipeWire.
Interesting... This one reflects the project's vision. An easy way to add global audio effects. Technically there is nothing we do that can not be done directly in |
Although the |
|
But from my point of view it is not just about changing the name visible to the user. We have to be consistent. The string |
|
I see what you mean. I do like "EasyEffects" and love your project vision, but a transition to any name may not be easy. |
|
That is it. Just changing the name in our executable and in our window title is not enough. In order to have consistency many files will have to be updated. Imagine asking the user to get logs running the command Our configuration is set in schemas named similar to Part of this process can be done in bulk with something capable of editing multiple files. But I am not sure what would be done about the repository name and url. If we rename them to for example easyeffects we suddenly will have many users that won't know how to find our project. But if we keep it named pulseeffects it may be harder for people to realize that this is the easyeffects location... Maybe the proper move to a new name would require a new repository creation and deactivation of this one. |
|
I almost feel that this will become irrelevant, especially as packagers are now spreading the word about the pipewire change... I learned about the pipewire change by running the app in terminal then searching the arch wiki after it quit working. I then downgraded the app as I need audio to be rock solid stable on my main machine and am not ready to ditch pulse yet. Hopefully in the near future though I can give pipewire a test! By the way, I found this app after looking for a alternative to the Maxxaudio app they pre-install on some dell machines (in windows). Needless to say, this is way better and I wish there was a port for macOS and windows now. Whatever you do with the name, thank you so much for this app! I use it every day and it makes things sound awesome. |
|
Thanks @Overc1ocker! :-) When I finish the port to GTK4 I will make a decision about this. As you can see in #904 the next major release will have very big changes that will make it a more suitable candidate for an eventual rebranding:
But as I said before I think a rebranding will have to come together with a new repository creation. But I would like to have the current branches as well as the issues in this new repository. Is this possible? |
|
It seems that github is smarter than I thought and I can just rename the repository https://github.blog/2013-05-16-repository-redirects-are-here/ |
|
Application rebranding done in the gtk4 branch. I will wait for the gtk4 port to be ready before trying to change the repository name. Anyone curious about the amount of work required for "this simple change" XD can take a look at this commit 15662b6. |
|
After many months of work EasyEffects has been finally released and the repository renamed. This issue can be closed :-) |
|
How do we install it? It's not available on Flathub |
|
@Akryum Please install the latest test build at the bottom of this page. Ensure you have PipeWire 0.3.31 or later on your host system (check with EasyEffects is not formally released onto Flathub yet, but when it is you can remove the test build and install the Flathub stable one. Personally, before putting it on Flathub stable I mostly would like #1089 to be resolved somehow (eg. finding a way to give helpful errors if EasyEffects Flatpak is installed on systems with old or no PipeWire). |
Disclaimer: This ticket is not meant to be a command or criticism. I use PulseEffects every day because my speakers are too bassy and I need a system-wide equalizer to reduce the bass. I appreciate the development and support of PulseEffects. It facilitated my switch from Windows using EqualizerAPO to cut the bass to Linux, where
pulseaudio-equalizercaused audio glitches and PulseEffects saved me. I am only posting this ticket as a suggestion.Now, here's my suggestion and rationale.
"PulseEffects" seems to be named after "PulseAudio". In the latest version, it's only compatible with "PipeWire", and not "PulseAudio", despite still having "Pulse" in the name. Therefore, it seems like dropping PulseAudio merits a rename to "PipeWireEffects", "PipeEffects", or "PWEffects".
This would:
Here's an alternative suggestion:
Alternatively, leaving support for PulseAudio in the software with a disclaimer that maintenance of PulseAudio support has ceased could work. This would continue to allow PulseAudio users to use the software without their configurations breaking for now, and allow PipeWire users to use the software as well. This alternative lacks only the discoverability benefit for new PipeWire users.
The text was updated successfully, but these errors were encountered: