Mute toggle becomes a silent no-op after audio API transient failure (icons stay stuck until restart)

[tellang]

Describe the bug

After silence! has been running for a while (especially after auto_mute has fired at least once), the mute toggle becomes a silent no-op: clicking the tray icon, pressing a hotkey, or clicking the overlay does not flip the mic, and the visible icon does not change. The tray icon, tray menu label, and overlay can also drift out of sync with the OS mute state when an external app (Teams, Discord, OBS, the Windows sound panel) toggles the mic. Only fully exiting and relaunching silence! recovers the toggle.

This looks closely related to the resolved #33. The 250 ms ID_STATE_TIMER polling is in place, but every error branch on the audio path silently swallows failures, so when polling or a user toggle hits a transient IAudioEndpointVolume error, STATE.muted gets stuck and there is no UI feedback or recovery path.

To Reproduce

Stuck-toggle path:

1. Launch silence! v2.1.1 with Auto-Mute → "Mute after inactivity" enabled.
2. Let inactivity auto-mute fire at least once, then resume activity.
3. Try toggling mute via tray click, hotkey, or overlay button.
4. Observed: nothing moves. Tray icon, tray menu label ("Mute Microphone"/"Unmute Microphone"), and overlay icon all stay frozen on the cached state. The OS mic mute does not flip either.
5. Quit silence! → relaunch → toggle works again immediately.

External-source desync (close cousin to #33):

1. With silence! running, open Microsoft Teams (or Discord) and mute/unmute the microphone from there.
2. silence!'s tray icon and overlay do not reliably reflect the change.

Expected behavior

• A failed set_mute / current_mute_state call should produce visible feedback (toast, overlay flash, or tray balloon) so the user knows the audio API is unhappy and so the app can attempt recovery.
• External mute/unmute events should propagate to silence! immediately (event-driven), not only via 250 ms polling that can itself silently stall on Err.

Desktop

• OS: Windows 11 26200
• App version: silence! v2.1.1 (Rust rewrite, commit 2524ad2)
• Hardware: single USB capture device

Code analysis (static read of main @ 2524ad2, v2.1.1)

Three reinforcing problems:

1. STATE.muted is set in only two places: src/main.rs:2462 (startup) and 4337 (set_global_mute_state). The 250 ms timer registered at 2487 calls refresh_runtime_state() → refresh_mute_state() (5468-5485), which silently returns on current_mute_state() Err at 5469-5471. When the audio API is transiently unhappy, STATE.muted stops updating and nothing surfaces.

2. Every Err branch on the audio path is eprintln! only — no UI feedback, no retry, no fallback. The pattern has grown in v2.1.1:

   • toggle_mute_target: 4241
   • set_mute_target: 4252
   • apply_startup_auto_mute: 4263
   • start_hold_hotkey: 4271, 4297
   • start_hold_toggle_hotkey: 4305
   • release_hold_hotkey: 4333
   • apply_inactivity_auto_mute: 5518
   • new in v2.1.1 (commits c7d612c, 68dc4b1): default-device set/toggle from menu (3671, 3676) and from hotkey (4195, 4202, 4208, 4213, 4218).

3. There is no Core Audio change subscription anywhere in src/ (no RegisterControlChangeNotify, no IMMNotificationClient, no IAudioEndpointVolumeCallback). External mute/unmute relies entirely on the 250 ms polling, which itself is silent on Err. apply_auto_mute (5522-) and the activity-based unmute path trust set_mute's return value without re-reading GetMute.

The tray icon (refresh_tray_icon at 2786-), tray menu label (3326-3335), and overlay (4471-4509) all paint from the STATE.muted cache. Once the cache is stuck, every visible surface is stuck.

Suggestion

Smallest patch that covers both the stuck toggle and the #33-style external desync:

1. Subscribe to mute-change events at startup using IAudioEndpointVolume::RegisterControlChangeNotify / IAudioEndpointVolumeCallback. The callback's OnNotify should PostMessage(WM_AUDIO_MUTE_CHANGED, ...); route that in main_wnd_proc to refresh_mute_state(). The 250 ms timer can stay as a fallback.
2. Make refresh_mute_state() log the error instead of silently returning:

fn refresh_mute_state() {
    let muted = match current_mute_state() {
        Ok(muted) => muted,
        Err(err) => {
            eprintln!("failed to refresh microphone mute state: {err:?}");
            return;
        }
    };
    if !muted && STATE.lock().unwrap().auto_muted_by_inactivity {
        clear_inactivity_auto_mute_flag();
    }
    if STATE.lock().unwrap().muted != muted {
        set_global_mute_state(muted, true);
    }
}

3. (Optional, separate PR) Surface toggle Err to the user (overlay flash or tray balloon on the eprintln! paths above) so silent failure becomes visible.

Happy to send a PR — the RegisterControlChangeNotify boilerplate is ~50 lines under windows-rs.

Thanks for the great utility!

---

Diagnosed by static read with a Claude + Codex (gpt-5.5) pair; both arrived at the same root cause independently with the same file:line evidence.

[tellang]

Self-correction on the reproduction trigger

To be precise about what I actually observed: my Windows 11 machine is rarely powered off, and after silence! has been running for a long stretch (days) the tray/overlay icon eventually ends up in the inverted state versus the OS mic mute. I cannot pin the flip on a single deterministic event — auto-mute is a plausible suspect given the cache-update paths in the body, but I did not measure it precisely.

What I am certain about:

• The mute/unmute sound effects keep playing correctly while the icon is wrong.
• I navigate by ear because the visible UI cannot be trusted in this state.
• A full app restart immediately restores the correct visual.

So the static-read evidence in the body (silent Err branches + no Core Audio change notification + cached STATE.muted feeding every visible surface) still stands, but the user-facing trigger should be read as "long-running session accumulates desync" rather than a tight "right after auto-mute fires" guarantee. The fact that the audio path is fine while the visible path drifts is itself consistent with set_mute + play_*_sound succeeding on the actual Ok return value while a separate STATE.muted write either misses, races, or never gets reconciled.

[vertopolkaLF]

Tried to fix it in 2.1.2, pls check

[tellang]

Thanks, installed v2.1.2. Will ping back if anything goes sideways.

[tellang]

Recurrence on v2.1.2 — visual desync after PC was left running ~7 days (no sleep)

Left the PC powered on for about a week (away on a trip, no manual interaction). Came back, the tray icon was inverted vs the OS mic mute again. App restart fixed it instantly, same as before.

Pulled the Windows event log to constrain the trigger:

Source	Count (last 10 days)	Reading
Microsoft-Windows-Kernel-Power (ID 42 / 107 / 1)	0	System never slept. Suspend/resume is NOT the trigger.
Microsoft-Windows-Audio/Operational (Event ID 65, endpoint topology)	172	Audio device topology churned ~17 times/day while the app sat idle.
Application Error matching silence.exe	0	silence! never crashed.
silence.exe current process	started 2026-05-19 19:57, uptime ~6.95 days, CPU 116h accumulated	Process kept running through the whole away period.

So suspend/resume is out. silence! ran for 7 days, didn't crash, and the OS reshaped audio endpoints around it 172 times.

While doing an independent code re-read with a Codex pair, the strongest pointer the static read can give without an instrumented build is rebind_default_capture_volume at src/main.rs:900-905:

fn rebind_default_capture_volume(&mut self) -> Result<()> {
    let device = unsafe { capture_device(&self.enumerator, None)? };
    let device_id = unsafe { endpoint_device_id(&device)? };
    if self.device_id.as_deref() == Some(device_id.as_str()) {
        return Ok(());   // <-- early return on same device_id
    }
    ...

On a single-USB-mic setup the default capture device_id stays the same for the entire 7 days. Every OnDeviceAdded / OnDeviceRemoved / OnDefaultDeviceChanged posts a rebind, but this short-circuit means a fresh IAudioEndpointVolume::Activate + RegisterControlChangeNotify never happens after startup — silence! keeps trusting the original cached volume. If the underlying endpoint reference is silently invalidated by one of those 172 topology events (Core Audio is documented to be opaque about long-lived endpoint reference liveness), the cached callback stops firing while current_mute_state() polling can also return stale Ok without ever hitting the Err branch that triggers ensure_audio_notification_registration at src/main.rs:5693. STATE.muted never reconciles, visible surfaces stay frozen, audio path stays correct (because set_mute(None, ...) opens a fresh enumerator inside capture_volume() every call and reaches the live endpoint).

Static code reading can only narrow this to a hypothesis — the same-device_id short-circuit plus Core Audio's opacity around long-lived endpoint references is the strongest hint without an instrumented build. A debug build with OutputDebugString around the five paths listed at the end is the cheapest definitive answer.

Possible directions, in case any are useful:

1. Drop the same-device_id short-circuit at line 903, or guard it with an explicit endpoint health probe (GetMute round-trip on self.volume) before returning Ok.
2. Treat any topology-class IMMNotificationClient event as a hard rebind regardless of device_id.
3. Add a periodic identity check that compares self.volume's endpoint against a freshly enumerated one and forces a rebind on divergence.

The diagnostic blocker from my earlier comment still applies: every audio-path eprintln! (refresh_mute_state at 5688-5694, ensure_audio_notification_registration rebind at 2367-2372, the toggle/set/hold/auto-mute Err arms, the WM_AUDIO_MUTE_STATE_CHANGED arm at 3566) goes to stderr on a console-less app. None of these reach the user or a maintainer. Happy to run a debug build that swaps those for OutputDebugString (visible in DebugView/Sysinternals, no console required, no file IO surprises) so the next recurrence captures exactly which path fails.

Let me know how you'd like to proceed.