CachyOS / CachyOS/distribution

Onboard microphone breaks when explicitly selecting analog-stereo input (Ryzen HD Audio / ALC1220)

Open
#313 2 comments 2 reactions 0 assignees View on GitHub
bug
Dominant language
No language data
Stars
27
Forks
2
PR merge metrics
No merged PRs in 30d

Description

### Description

On CachyOS, audio recording via the onboard 3.5 mm microphone input (Ryzen HD Audio / Realtek ALC1220) behaves inconsistently depending on how the input source is selected.

The microphone physically works, but recording becomes corrupted or completely unusable **as soon as the input is explicitly set** to:

> **“Ryzen HD Audio Controller – Analog Stereo”**

Interestingly, recording can work temporarily when no explicit input source is selected (auto-routing), or when using a USB audio adapter.

Multiple users have reported similar behavior.

---

### Expected Behavior

* Recording from the onboard microphone (rear mic, 3.5 mm jack) should work reliably
* Explicitly selecting
`Ryzen HD Audio Controller – Analog Stereo`
as input should not break microphone capture

---

### Actual Behavior

* When the input source is explicitly set to
“Ryzen HD Audio Controller – Analog Stereo”, one or more of the following occur:

* Loud squealing / crackling noises
* Truncated recordings (only a fraction of the expected duration)
* No usable audio captured
* PipeWire / WirePlumber errors during node linking

* After unplugging a USB audio adapter and reconnecting the headset directly to the motherboard:

* Recording initially works while no explicit input is selected
* As soon as the onboard analog input is manually selected, the issue immediately reappears

---

### Steps to Reproduce

1. Install CachyOS with default PipeWire + WirePlumber setup
2. Connect a microphone via the onboard 3.5 mm rear mic jack
3. Open audio settings or use `pactl`
4. Explicitly select:

> Ryzen HD Audio Controller – Analog Stereo
> as the input source
5. Record audio (e.g. browser mic test, `arecord`, OBS, Discord)

➡️ **Result**: recording is corrupted or unusable

---

### Workarounds

* Use a USB audio adapter (works reliably)
* Do not explicitly select an input source and rely on auto-routing (temporary)

---

### System Information

#### Distribution

* CachyOS
* Kernel: `6.18.1-2-cachyos`

#### Audio Stack

* PipeWire: `1.4.9`
* WirePlumber: active
* PulseAudio compatibility layer (PipeWire)

---

### Hardware

* Onboard Audio:

* AMD Ryzen HD Audio Controller
* Codec: Realtek ALC1220
* GPU Audio: NVIDIA AD103 (HDMI)
* USB Audio (working):

* Generic USB audio adapter
* HP 325 FHD Webcam (USB audio)

---

### Relevant Outputs / Logs

#### `inxi -A`

```text
Audio:
Device-1: NVIDIA AD103 High Definition Audio driver: snd_hda_intel
Device-2: AMD Radeon High Definition Audio driver: snd_hda_intel
Device-3: AMD Ryzen HD Audio driver: snd_hda_intel
Device-4: HP 325 FHD Webcam driver: snd-usb-audio
API: ALSA v: k6.18.1-2-cachyos
Server: PipeWire v: 1.4.9
```

#### `pactl info`

```text
Server Name: PulseAudio (on PipeWire 1.4.9)
Default Sink: alsa_output.pci-0000_0c_00.6.analog-stereo
Default Source: alsa_input.pci-0000_0c_00.6.analog-stereo
```

#### Active input (problematic)

```text
alsa_input.pci-0000_0c_00.6.analog-stereo
Port: analog-input-rear-mic
```

---

### WirePlumber / PipeWire Log Excerpts

```text
wp-event-dispatcher: link failed: 1 of 1 PipeWire links failed to activate
wp-event-dispatcher: failed to activate item: Object activation aborted: proxy destroyed
wp-event-dispatcher: some node was destroyed before the link was created
```

These messages appear repeatedly when switching or explicitly selecting the onboard input source.

---

### Additional Notes / Observation

After reconnecting the headset directly to the motherboard:

* Recording works as long as no explicit input source is selected
* The issue only appears once the analog-stereo input is manually selected

This strongly suggests:

* The microphone hardware and ADC are functional
* The issue is related to PipeWire/WirePlumber routing or profile selection
* A correct mono/rear-mic capture path likely exists but is not exposed or prioritized correctly

---

### Already Tested

* Restarting PipeWire and WirePlumber
* Switching audio profiles
* Replugging devices
* USB audio adapter (works reliably)

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.