I have diagnosed and fixed the issue with claude code. what follows is the report of what it did:

### System details

ASUS ROG Strix G16 (2025) on Omarchy 3.4.1 Intel(R) Core Ultra 9 275HX  NVIDIA GeForce RTX 5070 Ti
**Audio Hardware:** Intel 800 Series ACE (Audio Context Engine) + Realtek ALC285 codec
**Subsystem ID:** `0x10433f20` (ASUS)
**Date:** 2026-02-28

---

## Symptoms

- No sound from headphones (3.5mm jack) despite audio appearing to play normally in applications
- PipeWire reports volume at 30% and mute off — giving the false impression everything is configured correctly
- Browser (Chromium) shows an active audio stream routed to the correct output device
- Sound works after manually running `amixer` unmute commands, but **breaks again after every reboot** — `alsactl store` / `alsa-restore.service` does not persist the fix

---

## Root Cause

There are two interacting problems:

### Problem 1: Hardware mixer controls default to muted

The kernel's HDA driver for the ALC285 codec with ASUS subsystem ID `0x10433f20` does not initialize the ALSA hardware mixer controls to sensible defaults:

| Control | State Found | Expected |
|---------|------------|----------|
| `Master Playback Switch` | **off** (muted) | on |
| `Master Playback Volume` | **0** (0%) | > 0 |
| `Headphone Playback Switch` | off (muted) | on |
| `Line Out Playback Volume` | 0 (0%) | > 0 |

### Problem 2: Omarchy's `api.alsa.soft-mixer = true` prevents PipeWire from fixing it

Omarchy's ASUS ROG audio fix (`install/config/hardware/fix-asus-rog-audio-mixer.sh`) installs a WirePlumber config that enables software-only volume control:

```
# ~/.config/wireplumber/wireplumber.conf.d/alsa-soft-mixer.conf
monitor.alsa.rules = [
  {
    matches = [ { device.name = "~alsa_card.*" } ]
    actions = { update-props = { api.alsa.soft-mixer = true } }
  }
]
```

This causes a conflict:

1. **With soft-mixer enabled**, PipeWire controls volume in software and **does not touch ALSA hardware mixer controls at all**. It never uses the standard mixer paths (`analog-output-headphones.conf`, `analog-output-speaker.conf`) that would normally unmute/mute the `Headphone` and `Speaker` switches based on jack detection.

2. **The kernel's HDA jack detection handler** fires during codec initialization and resets the `Headphone Playback Switch` to `off` based on the codec's automute logic for this fixup (`ALC285: picked fixup for PCI SSID 1043:3f20`).

3. **`alsa-restore.service`** runs at boot and restores the saved state (including `Headphone = on`), but the kernel's jack detection fires again later (when PipeWire opens the device) and **overrides the restored state**, setting `Headphone` back to `off`.

4. **The Omarchy install script** (`fix-asus-rog-audio-mixer.sh`) only unmutes `Master` — it never touches `Headphone` or `Speaker`. With soft-mixer blocking PipeWire from managing these switches, nothing ever unmutes them.

The result: `Master` and `Line Out` volume persist correctly across reboots (since nothing overrides them), but `Headphone Playback Switch` is always reset to `off` by the kernel driver, and nothing re-enables it.

### Boot timeline showing the conflict

```
t=22.5s  Kernel: snd_hda_codec_alc269 - ALC285 codec initialized, fixup applied
t=23.4s  Kernel: HDA Intel PCH Headphone jack detection fires → Headphone switch = off
t=24.0s  alsa-restore.service: restores saved state → Headphone switch = on
t=28.8s  PipeWire opens device → jack detection fires again → Headphone switch = off
         PipeWire (soft-mixer=true): does NOT manage hardware switches → Headphone stays off
```

---

## Diagnosis Steps

### 1. Verify PipeWire services are running

```bash
systemctl --user status pipewire pipewire-pulse wireplumber
```

All three services should show `active (running)`. On this system they were running correctly — the issue was not with PipeWire itself.

### 2. Check audio hardware detection

```bash
cat /proc/asound/cards
```

Expected output showing two cards:
```
 0 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0x84080000 irq 17
 1 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0x8000210000 irq 241
```

Card 1 (PCH / Intel) is the one with the laptop speakers and headphone jack.

### 3. Check PipeWire sink status

```bash
pactl list sinks short
```

Look for the Intel/ACE sink and confirm it shows `RUNNING` (not `SUSPENDED`):
```
56  alsa_output.pci-0000_80_1f.3.analog-stereo  PipeWire  s32le 2ch 48000Hz  RUNNING
```

### 4. Check WirePlumber routing

```bash
wpctl status
```

Confirm audio streams are connected to the correct sink. In our case, Chromium was correctly routed to `ALC285 Analog` with active links — ruling out a routing problem.

### 5. Check port availability

```bash
pactl list sinks | grep -E "Active Port:|availability"
```

This revealed:
- `analog-output-speaker`: **not available** (headphone jack detection reporting headphones plugged in)
- `analog-output-headphones`: **available** (active)

This is normal behavior when headphones are plugged in — the system auto-switches to headphone output.

### 6. Check PipeWire volume and mute (misleading)

```bash
wpctl get-volume @DEFAULT_AUDIO_SINK@
```

Reported `Volume: 0.30` — this is the **software mixer** value, not the hardware state. This is what makes the issue confusing: PipeWire thinks everything is fine.

### 7. Install alsa-utils and inspect hardware mixer (the key step)

```bash
sudo pacman -S alsa-utils
amixer -c 1 contents
```

This revealed the actual problem — the hardware-level controls were muted/zeroed:
```
numid=9,iface=MIXER,name='Master Playback Switch'
  : values=off                          # <-- MUTED

numid=8,iface=MIXER,name='Master Playback Volume'
  : values=0                            # <-- ZERO VOLUME

numid=2,iface=MIXER,name='Headphone Playback Switch'
  : values=off,off                      # <-- MUTED

numid=1,iface=MIXER,name='Line Out Playback Volume'
  : values=0,0                          # <-- ZERO VOLUME
```

### 8. Check for soft-mixer config (the persistence blocker)

```bash
cat ~/.config/wireplumber/wireplumber.conf.d/alsa-soft-mixer.conf
```

If this file exists and contains `api.alsa.soft-mixer = true`, it is preventing PipeWire from managing the hardware mixer controls — which is why the headphone switch keeps reverting to `off` after every reboot.

---

## Fix

### Remove the soft-mixer WirePlumber config

```bash
rm ~/.config/wireplumber/wireplumber.conf.d/alsa-soft-mixer.conf
```

Then restart PipeWire:

```bash
systemctl --user restart wireplumber pipewire pipewire-pulse
```

### Why this works

Without `api.alsa.soft-mixer = true`, PipeWire uses the standard ALSA card profile mixer paths (`/usr/share/alsa-card-profile/mixer/paths/analog-output-headphones.conf`) to manage hardware controls. When the `analog-output-headphones` port is active, PipeWire:

- **Unmutes** the `Headphone` switch (via `[Element Headphone] switch = mute`)
- **Unmutes** the `Master` switch (via `[Element Master] switch = mute`)
- **Mutes** the `Speaker` switch (via `[Element Speaker] switch = off`)
- Manages `Master` and `Line Out` volume through the hardware

This happens every time PipeWire initializes the device, so it **overrides the kernel driver's broken defaults** reliably on every boot. WirePlumber also stores and restores route properties (volume, mute) in `~/.local/state/wireplumber/default-routes`, providing persistence independent of `alsactl store`.

### Verify the fix

After restarting PipeWire, check that the hardware controls are correct:

```bash
amixer -c 1 sget 'Headphone'    # Should show [on]
amixer -c 1 sget 'Speaker'      # Should show [off] (when headphones plugged in)
amixer -c 1 sget 'Master'       # Should show [on] with volume > 0
amixer -c 1 sget 'Line Out'     # Should show volume > 0
```

Then **reboot** and verify sound works without any manual intervention.

---

## Quick One-Liner Fix

```bash
rm ~/.config/wireplumber/wireplumber.conf.d/alsa-soft-mixer.conf && systemctl --user restart wireplumber pipewire pipewire-pulse
```

---

## Suggested Fix for Omarchy

The file `install/config/hardware/fix-asus-rog-audio-mixer.sh` should be updated. The current version:

```bash
# Current (broken for headphone persistence)
if omarchy-hw-asus-rog; then
  mkdir -p ~/.config/wireplumber/wireplumber.conf.d/
  cp $OMARCHY_PATH/default/wireplumber/wireplumber.conf.d/alsa-soft-mixer.conf ~/.config/wireplumber/wireplumber.conf.d/
  rm -rf ~/.local/state/wireplumber/default-routes

  card=$(aplay -l 2>/dev/null | grep -i "ALC285" | head -1 | sed 's/card \([0-9]*\).*/\1/')
  if [[ -n $card ]]; then
    amixer -c "$card" set Master 80% unmute 2>/dev/null
  fi
fi
```

The soft-mixer config should be removed. PipeWire's default behavior (using hardware mixer paths) correctly manages the `Headphone`, `Speaker`, and `Master` switches based on jack detection. The initial `Master 80% unmute` during install is still useful for first boot before PipeWire has stored route state:

```bash
# Proposed fix
if omarchy-hw-asus-rog; then
  # Remove the soft-mixer override — PipeWire's default hardware mixer
  # management correctly handles Headphone/Speaker switching via
  # alsa-card-profile mixer paths (analog-output-headphones.conf).
  # With soft-mixer enabled, PipeWire never touches ALSA switches,
  # and the kernel's HDA jack detection leaves Headphone muted.
  rm -f ~/.config/wireplumber/wireplumber.conf.d/alsa-soft-mixer.conf

  # Unmute Master on initial install (PipeWire will manage it from here)
  card=$(aplay -l 2>/dev/null | grep -i "ALC285" | head -1 | sed 's/card \([0-9]*\).*/\1/')
  if [[ -n $card ]]; then
    amixer -c "$card" set Master 80% unmute 2>/dev/null
    amixer -c "$card" set Headphone unmute 2>/dev/null
    amixer -c "$card" set Speaker unmute 2>/dev/null
  fi
fi
```

---

## Notes

- The `-c 1` flag targets ALSA card 1 (Intel PCH). If your Intel audio is on a different card number, check with `cat /proc/asound/cards` and adjust accordingly.
- The `analog-output-headphones.conf` mixer path automatically mutes speakers when headphones are plugged in, and vice versa — this is normal expected behavior.
- PipeWire's volume controls (via `wpctl`, `pavucontrol`, or Waybar) now directly control the hardware volume, giving accurate representation of the actual output level.
- This issue may affect other ASUS ROG laptops (Strix, Zephyrus, SCAR) using the Realtek ALC285 codec with the Intel 800 Series ACE audio controller.
- The `alsa-utils` package and `alsactl store` / `alsa-restore.service` are **not needed** for this fix. PipeWire and WirePlumber handle state persistence through their own route storage (`~/.local/state/wireplumber/default-routes`).