Assist Microphone: CPU spin-loop when no audio device is available

[NilesDavis]

Describe the issue you are experiencing

Add-on: Assist Microphone (Wyoming Satellite)
Home Assistant OS: 17.3
Home Assistant Core: 2026.5.4

Description

When the Assist Microphone add-on is enabled but no audio input device is connected to the host system, the add-on enters a crash-loop that causes sustained high CPU usage on the host (25–35% across 8 vCPUs), rendering the entire Home Assistant instance unresponsive.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Which app are you reporting an issue with?

Whisper

What is the version of the app?

Assist Microphone 1.3.0

Steps to reproduce the issue

1. Install and enable the Assist Microphone add-on
2. Have no physical audio input device connected to the host
3. Start or restart Home Assistant OS

System Health information

System Information

version	core-2026.5.4
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
container_arch	amd64
user	root
virtualenv	false
python_version	3.14.2
os_name	Linux
os_version	6.12.85-haos
arch	x86_64
timezone	Europe/Berlin
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	5000
Installed Version	2.0.5
Stage	running
Available Repositories	3183
Downloaded Repositories	54

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 17.3
update_channel	stable
supervisor_version	supervisor-2026.05.0
agent_version	1.8.1
docker_version	29.3.1
disk_total	47.5 GB
disk_used	34.7 GB
nameservers	10.0.0.150
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization	kvm
board	ova
supervisor_api	ok
version_api	ok
installed_addons	AirCast (5.1.1), Studio Code Server (6.0.1), chrony (6.0.1), MariaDB (3.0.1), InfluxDB (5.0.2), File editor (6.0.0), Samba share (12.6.1), Mosquitto broker (7.1.0), CEC Scanner (4.0), Assist Microphone (1.3.0), Whisper (3.1.0), Piper (2.2.2), ESPHome Device Builder (2026.5.1), evcc (0.307.1), Matter Server (8.5.0), NetBird (v0.71.4), Tailscale (0.28.1), OpenThread Border Router (2.16.8)

Dashboards

dashboards	7
resources	21
views	16
mode	storage

Network Configuration

adapters	lo (disabled), enp0s18 (enabled, default, auto), hassio (disabled), docker0 (disabled), wt0 (disabled), veth8797269 (disabled), veth7a5c089 (disabled), vethcca7e69 (disabled), vethe2750f1 (disabled), veth2292914 (disabled), veth511eddb (disabled), vethbc9a363 (disabled), veth1d39341 (disabled), veth3c8f3f3 (disabled), wpan0 (disabled)
ipv4_addresses	lo (127.0.0.1/8), enp0s18 (10.0.3.1/16), hassio (172.30.32.1/23), docker0 (172.30.232.1/23), wt0 (100.74.224.38/16), veth8797269 (), veth7a5c089 (), vethcca7e69 (), vethe2750f1 (), veth2292914 (), veth511eddb (), vethbc9a363 (), veth1d39341 (), veth3c8f3f3 (), wpan0 ()
ipv6_addresses	lo (::1/128), enp0s18 (fe80::575c:96eb:ad5c:ee5e/64), hassio (fd0c:ac1e:2100::1/48, fe80::3e:c3ff:fe4a:8726/64), docker0 (fe80::9c72:d2ff:fe88:9a41/64), wt0 (), veth8797269 (fe80::9822:b2ff:fe71:d0be/64), veth7a5c089 (fe80::70ef:daff:fe35:b92d/64), vethcca7e69 (fe80::bcd4:e5ff:fe71:a8cd/64), vethe2750f1 (fe80::fcc4:89ff:feb5:5e37/64), veth2292914 (fe80::1047:33ff:fe7a:bd09/64), veth511eddb (fe80::78b9:94ff:feb1:b3d8/64), vethbc9a363 (fe80::38dc:37ff:feab:c84a/64), veth1d39341 (fe80::9476:82ff:feac:bc94/64), veth3c8f3f3 (fe80::b812:98ff:feed:1f8a/64), wpan0 (fd8e:26ab:231e:56fc:0:ff:fe00:fc11/64, fda1:bfda:31e4:1:4032:bad3:af0a:11c1/64, fd8e:26ab:231e:56fc:0:ff:fe00:fc38/64, fd8e:26ab:231e:56fc:0:ff:fe00:fc10/64, fd8e:26ab:231e:56fc:0:ff:fe00:fc00/64, fd8e:26ab:231e:56fc:0:ff:fe00:5000/64, fd8e:26ab:231e:56fc:fd7e:57ee:d10d:8ee1/64, fe80::d030:6fcf:ed8e:8258/64)
announce_addresses	10.0.3.1, fe80::575c:96eb:ad5c:ee5e

Recorder

oldest_recorder_run	13. Mai 2026 um 09:12
current_recorder_run	26. Mai 2026 um 12:54
estimated_db_size	3311.40 MiB
database_engine	sqlite
database_version	3.49.2

Xiaomi Miot

component_version	1.1.4
can_reach_server	ok
can_reach_spec	ok
logged_accounts	0
total_devices	0

Anything in the Supervisor logs that might be useful for us?

Anything in the app logs that might be useful for us?

Additional information

Expected Behavior

The add-on should detect at startup that no audio device is available, log a clear error message, and exit cleanly — or at minimum apply an exponential backoff between retry attempts to avoid CPU saturation.

Actual Behavior

The underlying wyoming_satellite process (arecord in a loop) continuously attempts to open the audio device, fails, crashes, and is immediately restarted. This loop consumes 200%+ CPU (as seen in the host top output) and eventually makes the HA web UI, Zigbee, and all other integrations unresponsive. The VM cannot be gracefully rebooted and requires a forced stop from the hypervisor.

The issue only resolves itself after many forced reboots (sometimes 8, sometimes 30+), presumably due to timing effects during startup.

Root Cause

No startup check for audio device availability. No retry backoff. The Supervisor does not appear to detect or throttle the crash-loop.

Suggested Fix

• Check for a valid audio input device before starting arecord; exit with a descriptive error if none is found

Impact

High — the add-on silently degrades the entire HA instance without any visible warning in the UI. Users are unlikely to identify Assist Microphone as the cause since the add-on UI shows no obvious error state.