https://bugs.kde.org/show_bug.cgi?id=456310
Eduardo <eduardo.c...@kdemail.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eduardo.c...@kdemail.net
--- Comment #6 from Eduardo <eduardo.c...@kdemail.net> ---
I suffer a lot from this issue. I use pipewire with a virtual sink, and I use
Carla with some LSP - Linux Studio Plugins - equalizer/crossover on top of the
virtual sink routing to the real sink.
My default sink is the virtual sink, and that's the one that should have the
volume being controlled. However, most of the times, the applet changes the
volume of the real sink. Just like the OP's video. But for me it's somewhat
random, sometimes it works correctly, sometimes it doesn't. Regardless of
something being played back or not.
I've looked into the code, in this file
https://invent.kde.org/plasma/plasma-pa/-/blob/master/src/pulseaudio.cpp there
is a method called "findPreferredSink()" in line 271.
>From reading the code, I understand there are 2 distinct concepts: "default
sink" and "preferred sink. "Default sink" is the selected sink on the applet's
UI, and "preferred sink" is a guess of what sink should have the volume
controlled based on the playback state. For instance, if "sink A" is the
selected "default sink" in the UI but it happens to not have any playback going
on, while another "sink B" does have playback going on, then the code would
select "preferred sink" as "sink B", not "sink A", and volume changes would
affect "sink B" and not "sink A". That seems to be with the best of intentions,
however something is not working correctly in the case of virtual pipewire
sinks.
I don't see any obvious logic error by reading the code and running it
mentally. But I haven't managed to debug it since I don't know of an easy way
to compile and run this applet and see some sort of console output.
Simple fix would be to just disregard this "preferred sink" concept at all and
just always adjust the volume of the selected "default sink". However that
feature is there for 7 years and I guess most KDE mantainers would not agree to
delete an already deployed feature like this.
So... maybe someone can properly debug this code and find the bug? Perhaps
pipewire is guilty of not reporting the correct state of its devices, if we can
debug and show that it is the case, we should file a bug report in pipewire. Or
perhaps there is a logic bug in this code that I'm not seeing now.
--
You are receiving this mail because:
You are watching all bug changes.
