## Summary

On Apple Silicon, Omarchy ships Voxtype with `audio.device = "default"`. That default is unsafe on this hardware: WirePlumber can persistently pin Voxtype's capture stream to the headset-jack source, which emits **literal digital zeros** when nothing is plugged into the jack. Dictation then records silence forever, with no error in any log, and the pin survives both reboots and `omarchy voxtype remove && omarchy voxtype install`.

## Why Apple Silicon is different

Omarchy builds the only usable internal-mic path itself, via `omarchy-audio-asahi-mic-map`:

```
alsa_input.platform-sound.RawMics
  -> audio_effect.j314-mic         (DSP filter chain)
  -> omarchy_asahi_mic             (null sink, Audio/Sink)
  -> omarchy_asahi_mic.monitor     (the actual capture source)
```

Alongside it, the HiFi UCM profile permanently exposes `alsa_input.platform-sound.HiFi__Headset__source`. With nothing in the jack that source is not a quiet mic — it is digital silence:

```
$ pw-record --target=alsa_input.platform-sound.HiFi__Headset__source -r 16000 -c 1 --format s16 headset.wav   # 5 s
peak = 0   rms = 0   (-99.0 dBFS)   # literal zero samples
```

For comparison, the same 6 s through `default` while speaking normally:

```
peak = 10769 (-9.7 dBFS)   rms = 1300 (-28.0 dBFS)
```

## The failure

WirePlumber persists per-application capture targets in `~/.local/state/wireplumber/stream-properties`. Voxtype had acquired one:

```
Input/Audio:application.name:PipeWire\sALSA\s\ovoxtype-cpu\c=
    {"mute":false, "channelVolumes":[1.000000, 1.000000],
     "target":"alsa_input.platform-sound.HiFi__Headset__source",
     "channelMap":["FL", "FR"], "volume":1.000000}
```

Voxtype was the **only** application in that file carrying a `"target"` key. Confirmed live during a recording:

```
$ pw-link -l
alsa_input.platform-sound.HiFi__Headset__source:capture_MONO
  |-> alsa_capture.voxtype-cpu:input_MONO

$ pactl list source-outputs
Source Output #37744
  Source: 61                      # HiFi__Headset__source
  application.name = "PipeWire ALSA [voxtype-cpu]"
```

while every other client on the box, including `arecord -D default`, landed correctly on source 130 = `omarchy_asahi_mic.monitor`.

## Why it is hard to diagnose

The failure is completely silent. Nothing logs an error — `voxtype setup check` passes, the mic-map service is healthy, gains are fine, nothing is muted. The only symptom is that whisper hallucinates the single word `"you"` from zero samples, on every attempt regardless of length:

```
Recording stopped (12.9s) ... Transcribed: "you"
Recording stopped (4.1s)  ... Transcribed: "you"
Recording stopped (2.3s)  ... Transcribed: "you"
Recording stopped (6.6s)  ... Transcribed: "you"
Recording stopped (1.7s)  ... Transcribed: "you"
```

To a user this reads as "dictation opens but can't hear me."

## Why reinstalling does not help

`omarchy-voxtype-remove` clears `~/.config/voxtype` and `~/.local/share/voxtype`, but nothing under `~/.local/state/wireplumber`. The pin is in WirePlumber state, so remove + install recopies the config and leaves the routing broken. Observed directly here: a reinstall did not change the behaviour.

## Reproduce

1. Apple Silicon Mac, nothing plugged into the headphone jack.
2. Get Voxtype's capture stream targeted at `alsa_input.platform-sound.HiFi__Headset__source` — e.g. while it is recording, `pactl move-source-output <id> alsa_input.platform-sound.HiFi__Headset__source`.
3. Dictate. Every result is `"you"` or empty, permanently, across reboots and reinstalls.

I can't say for certain how the target got set here in the first place — that is the one part I could not reproduce from a clean state. The durable problem is that `device = "default"` leaves Voxtype exposed to it at all, and that there is no diagnostic when it happens.

## Suggested fix

On Apple Silicon, point Voxtype at the mic explicitly rather than at `default`, so per-application graph state cannot re-route it. What worked here — an ALSA PCM pinned to the monitor:

```
# ~/.asoundrc
pcm.asahimic {
    type pipewire
    capture_node "omarchy_asahi_mic.monitor"
    hint { show on; description "Asahi internal mic array (Omarchy)" }
}
```

with `audio.device = "asahimic"` in `~/.config/voxtype/config.toml`. Voxtype enumerates it (`voxtype info devices` lists `asahimic`), links to `omarchy_asahi_mic:monitor_FL/FR`, and dictation works. It also starts reporting honest empty transcripts on silence instead of `"you"`, because it is finally receiving a real noise floor.

Having `omarchy-voxtype-remove` also drop the Voxtype entry from `~/.local/state/wireplumber/stream-properties` would make reinstall an effective recovery path.

## Secondary, from reading the source

`omarchy-voxtype-install` installs the AUR `voxtype` package on aarch64:

```bash
if [[ "$(uname -m)" == "aarch64" ]]; then
  omarchy-pkg-add wtype
  omarchy-pkg-aur-add voxtype
else
  omarchy-pkg-add wtype voxtype-bin
fi
```

but `omarchy-voxtype-remove` only ever drops `voxtype-bin`:

```bash
omarchy-pkg-drop voxtype-bin
```

Since `voxtype-bin` `Conflicts With: voxtype`, only one can be present, so an aarch64 install that took the AUR-`voxtype` path would not be removed. I did not reproduce this — this machine happens to have `voxtype-bin` (which is now built for aarch64 and `Provides: voxtype`, so the install script's "x86_64-only prebuilt binaries" comment looks out of date too).

## System

- Omarchy `4.0.3rc4-1`
- Apple MacBook Pro (14-inch, M1 Pro, 2021), aarch64, Asahi
- PipeWire / WirePlumber 1.6.8, `pipewire-alsa 1:1.6.8-1`
- `voxtype-bin 1.0.1-1`
- `omarchy-asahi-mic.service` active, correctly ordered `After=pipewire.service pipewire-pulse.service wireplumber.service`