## What happened

After `omarchy update` installed `linux-omarchy 7.2.5-3` and I rebooted into it,
audio over HDMI crackles constantly — but **only while the mouse is moving**.
With the pointer stationary the audio is perfectly clean.

Booting the stock `linux 7.2.3-arch1-3` kernel, which is still installed,
resolves it completely. Nothing else on the system changed.

## What I expected

HDMI audio to keep working as it did on `linux 7.2.3-arch1-3`.

## Steps to reproduce

1. On a Haswell machine with an Intel iGPU, set audio output to an HDMI sink.
2. Boot `linux-omarchy 7.2.5-3`.
3. Play audio (any source — reproduced in Chrome).
4. Move the mouse continuously. Audio crackles for as long as the pointer moves.

## Measurements

Xruns counted on the HDMI sink (`alsa_output.pci-0000_00_03.0.hdmi-stereo`)
via `pw-top -b`:

| Kernel | Mouse still | Mouse moving |
|---|---|---|
| `linux-omarchy 7.2.5-3` | 0 / 12s | **~80–88 / 12s** |
| `linux 7.2.3-arch1-3` | 0 / 12s | 0 / 12s |

The analog output (`alsa_input.pci-0000_00_1b.0`, the separate PCH controller)
measured **0 xruns even while playing concurrently with a failing HDMI sink**,
which localises the problem to the display audio controller at `0000:00:03.0`.

PipeWire's log shows the recovery loop driving the audible crackle:

```
XRun! rate:1024/48000 delay:6 max:41901 (20 suppressed)
spa.alsa do_prepare: start threshold:1024 duration:1024 rate:48000
spa.alsa log_write: Slave: Hardware PCM card 0 'HDA Intel HDMI' device 3
```

`delay:6` — the hardware reports 6 frames buffered, ALSA declares an underrun,
PipeWire calls `snd_pcm_prepare()`, and the cycle repeats many times per second.

## Likely mechanism

HDMI audio is transmitted in the video blanking intervals, so it shares the
display pipe. Hyprland uses hardware cursor planes (`Cursor buffer imported into
KMS` in the aquamarine log), so each pointer movement is a DRM atomic commit
against that same pipe. Something in 7.2.5-3 appears to have made those commits
disruptive to the audio stream on this generation of iGPU.

## Ruled out by measurement

These were each tested and are **not** the cause:

- `snd_hda_intel power_save=0 power_save_controller=N` — no effect
- PipeWire realtime priority (installed `rtkit`; `data-loop.0` went `TS` → `RR 20`) — no effect (80 → 88 xruns)
- Buffer size — per-period failure rate flat at 27.9% (quantum 1024) vs 29.0% (2048)
- CPU load — pegging all 4 cores changed it by only +12%
- Thermal throttling — `thermal_throttle` counters 0 on all cores, 58°C
- Monitor VRR — disabled (`vrr: false`)
- Shared interrupts — HDA card0 on IRQ 75 (CPU1), i915 on IRQ 73 (CPU2)

## System details

| | |
|---|---|
| Omarchy | 4.0.4-1 (stable channel) |
| Machine | Apple Macmini7,1 (Late 2014) |
| CPU | Intel Core i5-4278U @ 2.60GHz (Haswell) |
| GPU | Intel Haswell-ULT Integrated Graphics `[8086:0a2e]` (rev 09) |
| HDMI audio | Intel Haswell-ULT HD Audio Controller `[8086:0a0c]` (rev 09) |
| Analog audio | Intel 8 Series HD Audio Controller `[8086:9c20]` (rev 04) — Cirrus CS4208 codec |
| Display | MSI MAG274Q QD E2, 2560x1440@60 over HDMI |
| Pointer | Logitech MX Master 3 (Bluetooth) |
| Bad kernel | `linux-omarchy 7.2.5-3` (built 2026-09-14, installed 2026-09-17) |
| Good kernel | `linux 7.2.3-arch1-3` |
| Audio stack | PipeWire 1.6.8 / WirePlumber 1.6.8 |

Note: `omarchy debug --no-sudo --print` is documented but does not exist in
4.0.4-1 (`Unknown Omarchy command`), so the above was gathered manually.

## Workarounds

- Boot the stock `linux` kernel (Limine's `BOOT_ORDER` wildcard already exposes it).
- Or switch audio to the analog output, which is unaffected.