-
-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Presets preloading does not destinguish between speakers and jack output #1051
Comments
PipeWire and Pulseaudio handle headphones in a different way. So comparing them won't help much. I was expecting the Kill the current instance |
Here are the outputs: There seem to be relevant differences on lines 1844, 1865, 1988-2049. From what I see, the inbuilt and jack microphones are effected as well (there is also only a single device for them).
Let me know if there is anything else I can do to help fix the issue. |
I did not have time yet to investigate the pw-dump output but in easyeffects logs I see
So at least one profile change we are seeing. But once you remove the headphone another line like that should come when going back to the previous hardware profile. Strange... Could it be that under the hoods |
At this moment what I do is trying to get from PipeWire the current hardware profile. Maybe I am doing this wrong. Maybe PipeWire is giving the same profile as answer for speakers and headphones. What does Pavucontrol show in its |
I am not quite sure about this (I have zero experience with Linux audio), but if I correctly understand the pw-dump, the
So in my case, the |
Hi again @wwmm , I just wanted to ask whether there is any update about this issue. I am asking because I am getting the same issue on another laptop, so it does not seem to be an isolated case. Thanks! |
Hi! I did not have time yet. Once my vacation was over there were tons of things to do at my work. I will try to take a look at this again tomorrow. At this moment we are using |
@lakotamm I have updated the master branch with some changes that should fix this issue. It took more work than I was expecting but we are now using device routes instead of profiles to to the preset autoloading. Try to use the Arch package from AUR. It should be possible to use it on Manjaro. @Digitalone1 if you have headphones try to do some tests too. This is one more of those situations where the hardware I have does not show any problem. Both the current implementation as well as the old one works. So it will be good to have other people testing. At least to see if the new approach did not bring new problems. |
Unfortunately it's partially working on my system. I always found the autoloading profiles UI a bit confusing. The problem is that if I have the speakers and the headphones, I should see two entries in output devices while there's only one instead. Don't know in English, but in Italian I see now the same label for second and third row: Profile. Maybe the second should be Hardware Profile. Once I saved the profile for speakers, I see They overwrite each other, so if I save the one for headphones, I get it when I plug in the headphones, but removing them does not restore the one I wanted and previously set for the speakers. And the analogous case happens when I save the preset for speakers. |
I did not understand. If you have only one soundcard there will be only one entry in the output devices list. When a headphone is plugged the card profile or route changes. But the device is still the same.
Strange. The last line is the preset and the first two the device and the device route name. They should not be the same unless the preset was saved with the device or route name.
Ok. So your card is different from mine. I will have to combine the route and the device name when creating the file name. In my card they have different values. |
Strange. That is already done. One of my autoloading profiles is named like
What is inside your |
|
When the headphones are plugged another file with a different name should have been created. Something like |
I wonder if the solution I implemented before to allow profiles to be updated from the ui is removing all the previous profiles. I will take a look at it. |
So If I don't have the headphones plugged in, I can't set a profile autoload for them. It's not comfortable, don't you think? I know that is difficult to solve this issue, but if I have the speaker and the headphone for which I can set the profile, I expect to have them both in the drop down menu. At this moment I can set a profile for the headphones only after I plugged in them, and the profile for the speakers won't work.
Maybe I have to update the translation. |
No, the previous is deleted and a new one is created. |
Thanks you very much for your time! The good news:
The bad news:
So trying to create a new autoloading preset for the same device (yet different route) removes the old one
Just FYI here is a log of connecting and disconnecting headphones (with only one preset -for speakers -enabled):
|
That is the problem. I will have to think about another way to update profiles from the ui.
I see your point but trying to show in the ui profiles that are not active can make things way more complicated. Depending on the hardware there is a fair amount of possible combinations and not necessarily the user will know which one will actually work. For example when I am not using a headphone my sound card automatically switches to its optical port. The output device in this case is named Now imagine I plug a headphone. The optical port is not used anymore and the I did not even consider in the example above the fact I also have a hdmi card. If we follow the "good path" where we show comboboxes with all the possible devices we also have to take into account that not all sound cards will support the same routes. My monitor's hdmi card does not have jacks for headphones. So it makes no sense to show this value in its route combobox. It is not like it can not be done. We could query PipeWire about all the possible profiles for each of the available soundcards. The problem is that the code complexity involved escalates quickly. Creating a profile to the current available device and route is way easier. And the user does not have to know which combinations can actually work in his/her current setup. For example my card supports surround profiles and they will be in PipeWire's list. But I do not have these channels in my speakers or headphones. |
I am perfectly fine with the way it is now (having to plug a device to create a preload for it) - no need to over-complicate it. IMHO it would be nice to see the currently active "route". But that is not critical. Fixing this bug should be the last bit to make easyeffects usable on laptops: |
Master branch updated again. Now we check the device name and the route value. So it should not overwrite all the previous profiles anymore. I think it should work now. But for the reasons I explained in my last post I can not test this. When I plug a headphone my card goes from a digital to an analogical device with a different name. |
It works for me! Thank you very much for your time! |
Ok! Good to know this was finally fixed. |
Just tested on my system. It's working too me too. Thank you @wwmm. |
Ok. Let's close this issue :-) |
I think this is not resolved. I successfully created a preset autoload for my [Out] Speaker and it works. But when I plug in my headphones it does not unload the [Out] Speaker preset. The speakers and headphones are under a single device, like the OP. The preset I'm using improves the laptop speakers' sound but shouldn't be applied while using headphones. Should autoloading also autounload, or is that beyond the scope of the feature and I'm sol? |
Hi @mueslimak3r. Are you using the latest master branch? Which files are under the autoload folder? Post also a screenshot of the autoload tab if you can. |
|
This is not true. With the latest changes you can do it. I'm afraid you are not using the latest master branch. Test |
You do not automatically autounload, instead, you load another preset (which can be empty). The way I do it:
But again, this is possible only if you are using the latest version from master. I can confirm that self-compiled flatpak (manually modified to refer to the latest commit) works as well. |
I think the problem is Pipewire changing your route to |
That is right. You have to create a profile that will load another preset when another device becomes EasyEffects output device. The code that is printing the changed route notification is this one easyeffects/src/application.cpp Line 177 in c70d1fe
|
I have updated the master branch with more debug messages. @mueslimak3r recompile your AUR package. Let's see if something new is shown in the logs. |
I'm not sure how to disable just a microphone route. It looks like my laptop has just one sound card. Is there a way to do this in pipewire? |
So this is the problem
I have the feeling this is going to be tough to handle. PipeWire may be sending the signal about the route change before actually sending the signal about the device change. And as a result the check for the correct device id fails easyeffects/src/application.cpp Line 191 in dc4a23a
This is the only thing that comes to my mind now. |
To be sure, try to print also the node id and the media class on the log. |
Gimme a shout if/when you need more logs (this time as a file). It looks like there's no new commits so I assume that's not a request for more logs from me. |
Run |
I think that the latest changes in EasyEffects |
Hello, I would like to report an issue with presets reloading. I am not able to switch profiles automatically when I plug in/unplug my headphones. Easyeffects sees only one output device, no matter whether I use headphones or inbuilt speakers.
This is the same error as #918. Everything works fine with Pulseeffects version 4.8 and pulseaudio.
OS: Manjaro Gnome,
Kernel: 5.12
easyeffects: 6.0.3
pipewire: 1:0.3.32-1
The text was updated successfully, but these errors were encountered: