omarchy-audio-output-sink fails to resolve physical sink for EasyEffects

[layolayo]

System details

Intel Core Ultra 7 155H, Intel Arc Graphics, Omarchy 4.0.3-1 (Lenovo ThinkPad X1 Carbon Gen 12)

What's wrong?

Summary

omarchy-audio-output-sink attempts to resolve virtual/DSP sinks like EasyEffects down to the physical hardware sink so that volume controls (both keyboard shortcuts and the Omarchy shell audio panel slider) act on real speaker loudness rather than altering the level going into the DSP processing chain.

However, the resolution check for EasyEffects in omarchy-audio-output-sink (lines 40–42) searches pactl list sink-inputs for application.name = "EasyEffects":

downstream="$(pactl list sink-inputs 2>/dev/null |
  awk -v virt="$sink" '
    /^Sink Input #/ {target = ""}
    /^[[:space:]]*Sink:/ {target = $2}
    /node\.name = / {
      name = $0
      sub(/.*node\.name = "/, "", name)
      sub(/"$/, "", name)
      if (index(name, virt) == 1 && target != "") {print target; exit}
    }
    /application\.name = "EasyEffects"/ {
      if (virt == "easyeffects_sink" && target != "") {print target; exit}
    }')"

In PipeWire, EasyEffects communicates natively via PipeWire SPA client nodes rather than through the PulseAudio emulation layer (pipewire-pulse). Therefore, application.name = "EasyEffects" never appears in pactl list sink-inputs.

Impact

1. omarchy-audio-output-sink fails to resolve easyeffects_sink to the physical sink and falls back to returning easyeffects_sink.
2. Both omarchy-audio-output-volume (volume keys) and Panel.qml (volumeSinkProc / Output slider in the shell audio panel) control easyeffects_sink instead of the physical sink.
3. Changing easyeffects_sink volume is largely absorbed or normalized by EasyEffects's limiter/compressor/autogain, resulting in little to no audible volume change when adjusting the slider.
4. If the underlying hardware sink is muted or at 0% (e.g. after booting or switching audio profiles), neither the volume keys nor the shell slider can raise or unmute the physical hardware speaker, leaving the system completely silent even while audio players show normal playback.

Steps to Reproduce

1. Install and run EasyEffects (systemctl --user enable --now easyeffects.service), routing output to laptop speakers (alsa_output.*.HiFi__Speaker__sink).
2. Run omarchy-audio-output-sink.
3. Notice it outputs easyeffects_sink instead of resolving to the downstream physical speaker sink (alsa_output.*.HiFi__Speaker__sink).
4. Mute the physical hardware speaker (pactl set-sink-mute <alsa_output_sink> 1) and try raising volume with keyboard volume keys or the Omarchy shell Output slider. Notice the physical speaker remains muted and at 0% volume.

Suggested Fix

When $sink == "easyeffects_sink", resolve the target downstream sink via active PipeWire links (pw-link -l) or EasyEffects configuration:

if [[ $sink == "easyeffects_sink" ]]; then
  # Check active PipeWire link
  target=$(pw-link -l 2>/dev/null | awk '$1 == "ee_soe_output_level:output_FL" {getline; print $2}' | cut -d: -f1)
  if [[ -n $target && $target == alsa_output.* ]]; then
    printf '%s\n' "$target"
    exit 0
  fi
  # Fallback to configured output device in easyeffects database
  target=$(grep '^outputDevice=' "${XDG_CONFIG_HOME:-$HOME/.config}/easyeffects/db/easyeffectsrc" 2>/dev/null | cut -d= -f2-)
  if [[ -n $target && $target == alsa_output.* ]]; then
    printf '%s\n' "$target"
    exit 0
  fi
fi

[rodrigo-castilla]

I have reproduced and analyzed the root cause. Rather than adding a hardcoded exception strictly for EasyEffects, I implemented a generic resolution step using native PipeWire links (pw-link -l) to trace downstream playback connections to physical endpoints (alsa_output.* / bluez_output.*).

It also retains backwards compatibility for PulseAudio sink-inputs and includes a fallback for EasyEffects when idle. Tested both in active streaming and idle states.

Opening a PR shortly with the fix.

[layolayo]

Fantastic solution! Gotta love the future of operating systems : long live Omarchy!

[martintanecek]

Hit this too (ThinkPad L14 Gen 1, Omarchy 4.0.4-1, PipeWire 1.6.8 / WirePlumber 0.5.17). Confirming the EasyEffects case, and adding a second failure mode that a pw-link-based fix for EasyEffects alone would not cover.

A plain module-filter-chain sink publishes a sink-input, and the resolver still fails on it.

The match requires the downstream stream's node.name to begin with the sink's name:

if (index(name, virt) == 1 && target != "") {print target; exit}

module-filter-chain names its nodes effect_input.<name> for the sink and effect_output.<name> for the stream, so the prefix test cannot succeed:

$ pactl get-default-sink
effect_input.Dolby_Balanced

$ pactl list sink-inputs | grep -E 'Sink:|node.name'
	Sink: 68
		node.name = "effect_output.Dolby_Balanced"

$ omarchy-audio-output-sink
effect_input.Dolby_Balanced        # expected alsa_output.pci-0000_00_1f.3.analog-stereo

The shipped dell-xps-2026 tuning passes only because it names its nodes omarchy_speaker_tuning and omarchy_speaker_tuning_output, which happen to satisfy the prefix test. So the heuristic works for Omarchy's own naming convention rather than for DSP sinks in general — a user-supplied filter-chain tuning hits the same silent fallback as EasyEffects.

Resolving through the PipeWire graph (as suggested above) would fix both at once, since node.link-group already ties a filter's input and output nodes together regardless of how they are named.

Workaround worth noting for anyone landing here: generating the tuning as a WirePlumber smart filter rather than a virtual sink sidesteps the whole thing. The hardware sink stays the default output, the filter inserts itself into the path, and omarchy-audio-output-sink has nothing to resolve — it returns the physical sink and the volume keys behave. Confirmed working on WirePlumber 0.5.17.

[rodrigo-castilla]

Thanks for confirming and bringing up the module-filter-chain edge case. That confirms that relying on node name heuristics is too fragile. Every issue is welcome!

The implementation in PR #12299 addresses this from both angles:

1. Generic PipeWire Graph Resolution (pw-link -l): By inspecting active downstream playback connections directly against physical hardware sinks (alsa_output.* / bluez_output.*), it bypasses naming conventions entirely (covering EasyEffects, module-filter-chain, and JamesDSP during playback).
2. Prefix-normalization in the PulseAudio fallback: I have also updated the fallback awk parser to account for the effect_input.<name> -> effect_output.<name> transformation used by module-filter-chain.

This ensures both native PipeWire nodes and virtual filter chains resolve down to the underlying physical sink seamlessly.

[omarchybot]

Update: #13396 has merged into quattro. The EasyEffects case is fixed. The separate effect_input/effect_output filter-chain naming case in later comments remains unresolved and is now tracked in #14236. This issue remains closed for its original EasyEffects report.

Scope checked by GPT-6 in Codex and Codex Medium against the discussion and landed change; review independence is not guaranteed. No tests were rerun for this cleanup.

Omabot on behalf of DHH