Repository navigation
Presets autoloading for unknown devices #1359
Description
EasyEffects Version
6.2.1
What package are you using?
Flatpak (Flathub)
Distribution
Fedora 35
Describe the bug
I would like to load a default preset for new devices instead of the plugins that are active at the moment when the device is connected.
The reason is as follows: I followed this tutorial (btw. thanks a lot, it is excellent). Now, my laptop speakers finally sound somehow reasonable!
This combination of plugins, however, only works well with my internal speakers and sounds horrible on everything else.
For everything else, I have a clean preset which does nothing.
Now, it's a bit cumbersome however, to always have to manually select the clean preset whenever I connect an external device (TV, external speakers etc.).
Instead, I would like to always apply the clean preset whenever a new device is connected.
Expected Behavior
No response
Debug Log
No response
Additional Information
No response
Activity
wwmm commentedon Jan 23, 2022
I have to think about this. The code responsible for the presets autoloading is becoming more complex than I had intended it to be. In any case there is a way you can reduce the current annoyance in you face in your installation. You can associate the
cleanpreset you already have to the other devices you do not want effects applied to. Once you switch to them thecleanpreset will be automatically loaded.I understand that you will have to go through the trouble of connecting each of these additional devices and creating the profile associated to the
cleanpreset. But it should work.bdaase commentedon Jan 23, 2022
That's exactly what I do at the moment and as you said, it works just fine. And it's also expected to become less trouble over time with more devices which have already been connected in the past. It's looking like this at the moment
Nonetheless, thanks for considering this. Hopefully we will find a good solution :)
wwmm commentedon Jan 23, 2022
I see. Your hdmi devices can generate different
Generic_*id when connected. Or are these actually different hardware? In any case when there are so many entries that have to be manually added that workaround definitely becomes annoying.Besides the implementation of the code that would do this there is also what to do about the user interface. Somehow the current behavior has to be the default while we allow the user to do something like the one you are asking.
bdaase commentedon Jan 23, 2022
Yeah, the four different
Generic_*sinks (3,7,8, and 9) always appear at once when an HDMI cable is connected and also disappear at the same time when it's disconnected. I didn't quite figure out what they are unfortunately (maybe one for HDMI, two for the USB-C ports?) but at least the ids are stable. Or do you have an idea how to get more information about them?Oh yeah, absolutely, we shouldn't change the default and I see that this is definitely tricky from a UI perspective. Perhaps we could ask one of the GNOME designers to have a look if we can't come up with a satisfying solution?
servimo commentedon Jan 23, 2022
I always thought that this extra sinks in HDMI are for 5.1 channels. Two are always for stereo, and the others center, left back, right back and LFE.
bdaase commentedon Jan 23, 2022
Interesting, thanks. But why are there only four extra
Generic_*sinks (3,7,8, and 9) appearing when I connect an HDMI cable? Shouldn't it be at least 5 then (bear with me please in case this is nonsense, I don't have lots of experience with audio)?wwmm commentedon Jan 23, 2022
Some of them are definitely for surround. The question is if the one related to stereo always has the same id or if the number can change on every boot.
If we are not able to find a way on our own I do not see any problem in asking someone else.
wwmm commentedon Jan 23, 2022
What you are seeing is not the number of channels but the card profiles. For example these are the profiles of my monitor's hdmi card
bdaase commentedon Jan 23, 2022
Ah, I see, thanks for the explanation. So the default names in my case are just terrible...
wwmm commentedon Jan 23, 2022
They will be better in the next EasyEffects release. The one you are using is not showing the
user friendly name. In our master branch we now show the device description like Pavucontrol does.bdaase commentedon Jan 23, 2022
The ones shown in pavucontrol aren't much better, I'm afraid
servimo commentedon Jan 23, 2022
My HDMI output in Pavucontrol:
bdaase commentedon Jan 23, 2022
So, it indeed looks like the IDs are stable indeed and
Renoir Radeon High Definition Audio Controller HDMI / DisplayPort 2 Outputis the stereo audio. Whatever the three others are, then....bdaase commentedon Jan 24, 2022
Do you have an idea against which project I could report these not really helpful sink names? Pipewire? Or is this baking a lower level issue?
wwmm commentedon Jan 25, 2022
I did not take a look at PipeWire's code but they probably take what ALSA is giving them and customize a little to make it more user friendly. So it is possible that the names you see can not be entirely changed in PipeWire.
bdaase commentedon Jan 26, 2022
Thanks. I talked to the pipewire folks in IRC and reported the issue against pipewire here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2067.
rmeissn commentedon Oct 27, 2022
I got the same problem as @bdaase: I applied a preset for my laptop speakers and like to use no preset for any other device. I also came up with the mentioned workaround from #1359 (comment), which works, but seems "wrong" to me.
The current implementation of easyeffects applies a preset to all devices, except stated differently. Actually, it should be the other way around: apply no preset by default, except stated differently for a device.
Even though it's counterintuitive to me, it's perfectly fine to keep the current implementation and to introduce a "everything else" device in the ~"automatically loaded presets" section, that I can map to a preset (e.g. one without any effects).
As the tool probably searches through this list anyway, it can always apply the most specific preset and if none is appliable, either use the previously used preset (current behaviour) or stick to the "everything else" device, if it is there. This way, it's only needed to add one additional if else statement to the code, as well as the "everything else" device.
EDIT: I'm on Fedora 36 and EasyEffects 6.3.0 from Flathub.
wwmm commentedon Oct 27, 2022
This is not technically correct. It does not apply a preset to all devices as in "load a preset file all the time". Preset file autoloading only happens when a profile matches a device. What is happening is that easyeffects remembers the last used settings. So if you do not change them they will be still active even if you restart it.
rensenware commentedon Oct 28, 2022
As a related issue, has there been any consideration for letting easyeffects autoload a preset on port change? My laptop's audio sink handles both the speakers and audio jack, switching between them by handling them as different ports on the same device. I cannot set a different preset for when I plug in my headphones or any other device on the jack due to this.
wwmm commentedon Oct 28, 2022
This already happens. At least in the hardware I have available for testing as well on the computer of a few users. But there is always a sound card that behaves differently from the majority. Maybe yours has some kind o unique behavior.
When a headphone or a microphone is plugged usually PipeWire automatically switches the hardware profile. And our autolaoding code makes use of it. Run
pw-dumpbefore and after plugging a headphone or a mic so we can see what PipeWire is doing differently in your laptop soundcard. But it is probably better to do this opening a new issue. Your problem is probably very different from the one discussed here.Also run EasyEffects in debug mode when you save the output of
pw-dump. First kill the current instanceeasyeffects -qand then restart it in debug modeG_MESSAGES_DEBUG=easyeffects easyeffects. This should help us to understand why the autoloading isn't working for you.jtl5770 commentedon Dec 24, 2022
Well, I can only second the problems and request for feature stated here :-) Also in my case - I have a heavy equalized preset for the internal speaker, and a flat (essentially empty) preset that I manually have to associate with every new bluetooth headphone I use (and, for some weird reason, I use a lot of them and they are also changing).
While this works, having the ability to mark one preset as the default that matches when no other matches would be really helpful and make the system basically work out of the box, regardless of what new headset I want to use with it (unless there is some specific stuff I want to change with that headset, but then I am happy to create a specialized preset for it)
spikespaz commentedon Jul 28, 2023
I vote that the closed issue be reopened because it describes the most likely correct solution.
neilbags commentedon Sep 9, 2024
Is it worth adding a link to this issue in the FAQ?
Its the first thing I tried to do after installing EasyEffects
wwmm commentedon Sep 9, 2024
Feel free to do it. There is no problem.
I am still not sure about the best way to handle this issue. And with the time I have free for EasyEffects going to the Qt port I have no idea about when a solution for the preset autoloading will be in place.
neilbags commentedon Sep 9, 2024
Done
Digitalone1 commentedon Sep 10, 2024
A workaround for this behaviour is to associate the preset considered as "default" to every used device. The problem is that it's not autoloaded to a new device connected for the first time.
Anyway this should be easy to implement in the Qt port. When a new device is signaled as default by Pipewire, we check for associated presets. If a preset is not found, we could just fallback to the "default preset" (if it's set in the preset settings).
wwmm commentedon Sep 10, 2024
Yes. A fallback will be necessary. But maybe behind a configuration option for the cases where this is really necessary. Having a preset being loaded all the time goes a little against of the purpose of having a database.
wwmm commentedon Aug 23, 2025
I think we can finally close this issue. The Qt branch has a
fallback presetfeature that can be used in this situation