[GH-ISSUE #673] [Volume] Volume module breaks default sink #4445

New issue

Closed

opened 2026-05-23 00:53:18 +01:00 by JakeStanger · 4 comments

JakeStanger commented

2026-05-23 00:53:18 +01:00

Owner

Originally created by @donovanglover on GitHub (Jul 21, 2024).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/673

Describe the bug
Was trying out the volume module and looks like pipewire sinks get messed up when connecting new devices.

To Reproduce
Steps to reproduce the behavior:

Have an external monitor with audio output
Plug in headphones
Default sink changes to external monitor instead of headphones
Unplugging the headphones and killing ironbar results in the external monitor continuing to be the default sink

Expected behavior
Should maintain the same audio switching as when ironbar isn't being used

System information:

Distro: NixOS unstable
Compositor: Hyprland
Ironbar version: github.com/JakeStanger/ironbar@58190ab079

Additional context
Causes pcieport 0000:00:08.1: PME: Spurious native interrupt! errors when connecting headphones

Originally created by @donovanglover on GitHub (Jul 21, 2024). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/673 **Describe the bug** Was trying out the volume module and looks like pipewire sinks get messed up when connecting new devices. **To Reproduce** Steps to reproduce the behavior: 1. Have an external monitor with audio output 2. Plug in headphones 3. Default sink changes to external monitor instead of headphones 4. Unplugging the headphones and killing ironbar results in the external monitor continuing to be the default sink **Expected behavior** Should maintain the same audio switching as when ironbar isn't being used **System information:** - Distro: NixOS unstable - Compositor: Hyprland - Ironbar version: https://github.com/JakeStanger/ironbar/commit/58190ab079d00dd53babb72346f1da6e1cc9ac72 **Additional context** Causes `pcieport 0000:00:08.1: PME: Spurious native interrupt!` errors when connecting headphones

JakeStanger

2026-05-23 00:53:18 +01:00

closed this issue
added the
A:Client

T:Bug
labels

JakeStanger commented

2026-05-23 00:53:18 +01:00

Author

Owner

@JakeStanger commented on GitHub (Nov 4, 2024):

Should maintain the same audio switching as when ironbar isn't being used

To confirm, the expected behaviour would be that it switches to the newly plugged in device right?

@JakeStanger commented on GitHub (Nov 4, 2024): > Should maintain the same audio switching as when ironbar isn't being used To confirm, the expected behaviour would be that it switches to the newly plugged in device right?

JakeStanger commented

2026-05-23 00:53:18 +01:00

Author

Owner

@donovanglover commented on GitHub (Nov 4, 2024):

Ideally ironbar doesn't switch anything at all since I'm using switch-on-connect already

@donovanglover commented on GitHub (Nov 4, 2024): Ideally ironbar doesn't switch anything at all since I'm using [`switch-on-connect`](https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-switch-on-connect) already

JakeStanger commented

2026-05-23 00:53:18 +01:00

Author

Owner

@JakeStanger commented on GitHub (Nov 5, 2024):

I've not been able to replicate this using pipewire-pulse at all. In my own testing:

On my desktop, (dis)connecting audio devices makes no difference. Audio playback continues where it was, the default remains the same and so ironbar's state also remains the same.
On my laptop, monitor/headphones get treated as a single two-port device and switching is instant, but does not show in ironbar.

In neither scenario did I get any errors or other logs from the audio server or ironbar.

I'm suspicious that it could be switch-on-connect or another program/option causing problems. Ironbar does not ever try to change the default device unless you select an option from the popup dropdown, so I think it's less likely to be the cause, at least with a generic/default setup.

If you're able to confirm, and if not provide more information and more detailed repro steps I'll keep investigating.

@JakeStanger commented on GitHub (Nov 5, 2024): I've not been able to replicate this using pipewire-pulse at all. In my own testing: - On my desktop, (dis)connecting audio devices makes no difference. Audio playback continues where it was, the default remains the same and so ironbar's state also remains the same. - On my laptop, monitor/headphones get treated as a single two-port device and switching is instant, but does not show in ironbar. In neither scenario did I get any errors or other logs from the audio server or ironbar. I'm suspicious that it could be `switch-on-connect` or another program/option causing problems. Ironbar does not ever try to change the default device unless you select an option from the popup dropdown, so I think it's less likely to be the cause, at least with a generic/default setup. If you're able to confirm, and if not provide more information and more detailed repro steps I'll keep investigating.

JakeStanger commented

2026-05-23 00:53:18 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 19, 2025):

I'm going to close this as I've never seen it occur and not heard back. Happy to re-open if any further information can be supplied.

@JakeStanger commented on GitHub (May 19, 2025): I'm going to close this as I've never seen it occur and not heard back. Happy to re-open if any further information can be supplied.