## System details

- Omarchy: `4.0.4-1`
- Kernel: `7.2.5-3-omarchy` (`linux-omarchy 7.2.5-3`)
- Laptop: Lenovo Legion Pro 7 16IRX8H, product `82WQ`
- CPU: Intel Core i9-13900HX
- GPUs: Intel Raptor Lake-S UHD Graphics and NVIDIA GeForce RTX 4080 Laptop GPU
- Audio controller: Intel `8086:7a50`, PCI subsystem `17aa:3846`
- Codec: Realtek ALC287, codec subsystem `17aa:3886`
- Speaker amplifier: `i2c-TIAS2781:00`, driver `tas2781-hda`
- PipeWire / pipewire-pulse: `1:1.6.8-1`
- WirePlumber: `0.5.17-1`
- linux-firmware / linux-firmware-other: `20260810-2`

## What's wrong?

The laptop's internal speakers are silent in Firefox and in system playback tests. The built-in analog output is selected, the active port is `analog-output-speaker`, and both the PipeWire output and ALSA Master/Speaker controls are unmuted. PCM volume is near 100%.

The observed problem is on the bundled Omarchy kernel. It is not yet established whether the underlying defect is Omarchy-specific or an upstream kernel issue. There is no known last-working kernel/version or confirmed update that introduced it.

### Reproduction on this machine

1. Boot normally without a `snd_hda_intel model=` override.
2. Select Built-in Audio Analog Stereo / Speakers.
3. Play audio in Firefox or run:
   ```sh
   paplay --device=alsa_output.pci-0000_00_1f.3.analog-stereo /usr/share/sounds/alsa/Front_Left.wav
   ```
4. Playback completes successfully, but the user hears nothing.

Expected: audible playback from the internal speakers.

### Diagnostics and troubleshooting

- PipeWire, pipewire-pulse, and WirePlumber were running.
- Restarting all three services, explicitly selecting the speaker port, unmuting, and setting volume to 65% did not restore audible sound; the user confirmed the test was silent.
- Direct ALSA playback through `plughw:CARD=PCH,DEV=0` completed without an error. Audibility of this separate test was not confirmed.
- A USB audio device and HDMI monitor were also connected; the explicit test above targets the laptop output.
- The TAS2781 driver was loaded and bound to its I2C device, but the initial boot log did not show the HDA codec binding the amplifier component.

Relevant initial boot log:

```text
snd_hda_codec_alc269 hdaudioC1D0: ALC287: picked fixup  for PCI SSID 17aa:3846
snd_hda_codec_alc269 hdaudioC1D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
snd_hda_codec_alc269 hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
snd_hda_codec_alc269 hdaudioC1D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
```

Later in the same boot, before the driver reload:

```text
snd_hda_intel 0000:00:1f.3: Unstable LPIB (260400 >= 8192); disabling LPIB delay counting
```

### Temporary diagnostic override — NOT a confirmed fix

With the user audio services stopped, reloading `snd_hda_intel` with `model=17aa:3886` caused the codec to bind the TAS2781 amplifier. A subsequent reload also included the amplifier's `snd_hda_scodec_tas2781_i2c` module. No persistent modprobe configuration was written.

Relevant resulting log:

```text
snd_hda_codec_alc269 hdaudioC1D0: ALC287: picked fixup  for alias SSID 17aa:3886
tas2781-hda i2c-TIAS2781:00: tasdevice_prmg_load: Firmware is NULL
snd_hda_codec_alc269 hdaudioC1D0: bound i2c-TIAS2781:00 (ops tas2781_hda_comp_ops [snd_hda_scodec_tas2781_i2c])
tas2781-hda i2c-TIAS2781:00: tas2781_apply_calib: V1 CRC error
```

After this override, `amixer -c PCH controls` lists these amplifier controls under `iface=CARD`:

```text
Speaker Analog Volume
Speaker Config Id
Speaker Force Firmware Load
Speaker Profile Id
Speaker Program Id
```

`Speaker Force Firmware Load` reads `on`. The model-specific firmware file exists:

```text
/usr/lib/firmware/ti/audio/tas2781/TAS2XXX3886.bin.zst
```

The audio services and built-in speaker output are back online, and playback tests complete. **The user has not yet confirmed audible playback after the override**, so this report does not claim that it fixes the issue. The calibration CRC error also remains unexplained.

The differing PCI and codec subsystem IDs, and the change in amplifier binding when explicitly selecting the codec ID, suggest a quirk-selection issue worth investigating.

### Diagnostic tooling

`omarchy debug --no-sudo --print` is not available on this installation (returns “Unknown Omarchy command”), and `omarchy commands --all` contains no debug command. Relevant targeted diagnostics are included above instead. No screenshot is attached because the failure is silent physical speaker output while playback appears successful.