mirror of
https://github.com/JakeStanger/ironbar.git
synced 2026-07-11 06:15:21 +01:00
[GH-ISSUE #1411] Issue: Volume module consistently switches focus to EasyEffects virtual sink #4643
Labels
No labels
A:Build
A:CI
A:Client
A:Config
A:Core
A:Documentation
A:Documentation
A:IPC
A:Testing
A:UX/UI
blocked
BREAKING CHANGE
duplicate
good first issue
GTK4
help wanted
invalid
M:Battery
M:Battery
M:Bindmode
M:Bluetooth
M:Brightness
M:Cairo
M:Clipboard
M:Clock
M:Clock
M:Custom
M:Focused
M:Keyboard
M:Launcher
M:Menu
M:Music
M:Music
M:Music
M:Network Manager
M:Notifications
M:SysInfo
M:Tray
M:Volume
M:Workspaces
partially resolved
P:Critical
P:High
P:Low
P:Medium
pull-request
T:Bug
T:Bug
T:Core Enhancement
T:Module Enhancement
T:New Module
T:Question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
JakeStanger/ironbar#4643
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ffs-akl on GitHub (Mar 5, 2026).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1411
Describe the bug
I am reporting a persistent issue where the volume module in ironbar automatically switches its focus to the EasyEffects virtual sink.
This is almost always triggered whenever media playback starts. Even if I manually switch the volume control back to the physical hardware device, it will frequently jump back to the EasyEffects sink after a short period. It seems the module is incorrectly tracking the "active" audio stream's node rather than sticking to the system's defined Default Sink.
Edited:
Refined Behavior Summary:
Trigger: The jumping almost always happens at the start of a new media stream (e.g., opening a new video or refreshing the page).
Manual Fix: If I manually switch back to the hardware sink during playback, it stays there for the duration of that stream.
Persistence of Bug: However, the moment I start a new video, the module resets its focus to the EasyEffects sink again after a brief period of violent oscillation.
Conclusion: The module seems to be "auto-focusing" on the most recently activated audio node instead of strictly adhering to the system's Default Sink metadata.
To reproduce
Steps to reproduce the behavior:
1.Install EasyEffects and ensure it is running in the background.
2.In both EasyEffects and ironbar, ensure the physical hardware audio device is selected/used as the default sink.
3.Start playing a video (e.g., in a browser or media player).
4.Observe the volume module in the bar; it will frequently and randomly switch its display/control to the "EasyEffects Sink" instead of the physical device.
Expected behavior
The volume module should consistently track and display the System Default Sink. It should remain persistent on the hardware output unless the default device is explicitly changed at the audio server level (PipeWire/WirePlumber).
System information:
Configuration
Config
Styles
Additional context
Screenshots
https://github.com/user-attachments/assets/1c2d542e-b638-46e6-a5db-225f5cd8d00e
@Brisingr05 commented on GitHub (Mar 13, 2026):
Thank you for reporting this, because I've been facing this issue for around 2 years but have been too lazy to make an issue (I just removed the module instead). This problem also causing CPU usage (and fan speed and temps) to shoot up, which is how I became aware of this issue in the first place.
@Kommynct commented on GitHub (Mar 17, 2026):
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/296 related, wish they'd add this, until now we need a manual way to ignore it.
@JakeStanger commented on GitHub (May 6, 2026):
This may have been fixed by either #1469 or #1475. Are you able to confirm if this is still happening on the latest commit please?
@ffs-akl commented on GitHub (May 7, 2026):
Thanks, This issue have been fixed.
@ffs-akl commented on GitHub (May 9, 2026):
ironbar-git-0.18.0.r235.g474d358
The issue doesn't seem to be fixed. It happens every time I switch to another video.
please see the viedo bleow
https://github.com/user-attachments/assets/05c1f7a3-fb35-4c55-bdf0-164d4eb78c27
@ffs-akl commented on GitHub (May 10, 2026):
ironbar-git-0.18.0.r239.g8d960d9
This issue seems to be fixed. It doesn't happen any more when I switch to another video.
@ffs-akl commented on GitHub (May 10, 2026):
Thanks very much!
@JakeStanger commented on GitHub (May 13, 2026):
From https://github.com/JakeStanger/ironbar/issues/1483#issuecomment-4415720622
Here is the log fie (set **both** `IRONBAR_LOG` and `IRONBAR_FILE_LOG`), it successfully preserved the setting
Here is the log fie (set **both** `IRONBAR_LOG` and `IRONBAR_FILE_LOG`), the default device incorrectly switched to EasyEffects
@JakeStanger commented on GitHub (May 17, 2026):
I've not had any luck reproducing this issue since the fixes went in. As this is a fairly minor issue and doesn't seem to be affecting most people, I'm going to move back to next release. If you get any more details in the meantime please do share and I'll investigate.
@Brisingr05 commented on GitHub (May 18, 2026):
FWIW this has no longer been an issue for me for a couple of weeks (I'm using the
masterbranch). No more rapid switching, high CPU usage etc.