AudioSwap hotfix 2.3.0

[BlackPaw21]

Changelog

If this pull request updates an existing mod, describe the changes below:

added Persistent Mute option
general patches
added screenshots to readme

Mod authorship

If this pull request introduces a new mod, please complete the section below.

This mod was created by:

• • The submitter, without AI assistance
• • The submitter, with AI assistance
• • Claude
• • ChatGPT
• • Gemini
• • Another AI (please specify):
• • Other (please specify):

Please select the options that best apply. Your selection does not affect the acceptance criteria, but it helps reviewers understand the context of the code and provide relevant feedback.

[m417z]

Submission review

Note: This review was done by Claude, and then refined manually. Due to the amount of submissions, doing a fully manual review for each pull request is no longer feasible. Thank you for understanding.

Please address the following issues. The items in the collapsed sections are optional, so it's your call whether to address them.

Note: I haven't verified the claims manually. If it's a mistake and the code is correct as is, let me know.

---

The new Persistent Mute feature has a device-tracking bug that leaves a device stuck muted.

Persistent mute never re-tracks the muted device after a swap, and never unmutes the previous one. When persistent mute is on and you cycle to a new device, CycleAudioDevice skips RestoreMute() (leaving the old device muted) and then mutes the new default with ApplyMute(nullptr, TRUE) — but it never updates g_mutedDeviceId, the persisted MutedDeviceId, or unmutes the old device:

// CycleAudioDevice — lines ~2022-2027
if (keepMute) {
    ApplyMute(nullptr, TRUE);   // mutes the new default...
    HWND hw = g_trayHwnd;       // ...but g_mutedDeviceId still points to the OLD device
    if (hw) PostMessageW(hw, WM_UPDATE_TRAY_STATE, 0, 0);
}

The same omission is in the WM_REBIND_VOLUME_CALLBACK branch (lines ~2674-2678). Because g_mutedDeviceId is now stale, everything that relies on it targets the wrong device:

• Manual unmute unmutes the wrong device. After a swap, ToggleMuteCurrentDevice/RestoreMute call ApplyMute(g_mutedDeviceId=oldDevice, FALSE), unmuting the old device while the current device stays muted. The user clicks unmute and nothing happens to the audible device.
• Reversibility is broken. On settings change / disable / uninit, RestoreMuteExternal() (line ~2876) restores the stale old ID, so the mod leaves the current device muted after it's turned off. Every intermediate device cycled through while muted is also left muted with no tracking.

Fix: when persistent mute re-applies the mute, release the previously muted device, mute + track the new default (you already know its ID — localIds[validSlot]), and persist it:

if (keepMute) {
    WCHAR prevId[512];
    { EnterCriticalSection(&g_stateLock); lstrcpynW(prevId, g_mutedDeviceId, 512); LeaveCriticalSection(&g_stateLock); }
    if (prevId[0] && wcscmp(prevId, localIds[validSlot]) != 0)
        ApplyMute(prevId, FALSE);                 // release the device we no longer point at
    ApplyMute(localIds[validSlot], TRUE);         // mute the new default
    EnterCriticalSection(&g_stateLock);
    lstrcpynW(g_mutedDeviceId, localIds[validSlot], 512);
    LeaveCriticalSection(&g_stateLock);
    Wh_SetStringValue(L"MutedDeviceId", localIds[validSlot]);
    HWND hw = g_trayHwnd;
    if (hw) PostMessageW(hw, WM_UPDATE_TRAY_STATE, 0, 0);
}

The WM_REBIND_VOLUME_CALLBACK path should retrack the same way (fetch the new default's ID and store it into g_mutedDeviceId / MutedDeviceId).

Optional improvements

Minor polish — none of this affects users, so it's your call.

• g_persistentMute locking is inconsistent with its stated invariant. It's declared inside the // protected by g_stateLock block (line 225), but it's written without the lock in the WM_RELOAD_ALL handler (line ~2685, tray thread) and WhTool_ModInit (line ~2853), and read without the lock at line ~2675 — while CycleAudioDevice reads it under the lock (line 1969). It's a plain bool, so this is benign in practice, but either take g_stateLock on those accesses or move it out of the guarded block (e.g. make it a volatile LONG / std::atomic<bool>) so the invariant comment stays honest.

Functionality notes

Non-critical observations about the feature behavior itself.

• WM_REFRESH_DEVICE_LIST can revert an unsaved slot selection. In the slot-combo repopulation loop (lines ~1092-1102) newSel is first set from the preserved current selection (findNewIdx(savedSlotSel[i])) but then unconditionally overridden by if (s->slots[i].id == activeDevices[j].id) newSel = idx;, which snaps the combo back to the last saved device ID. So if the user changes a slot dropdown without saving and a device is hot-plugged while the dashboard is open, their in-progress change is silently reverted. The priority combos (lines ~1104-1113) only use savedPrioSel and don't have this override, so the two panels behave differently. If preserving the live selection is intended, drop the s->slots[i].id override (or only apply it when savedSlotSel[i] was invalid).

[BlackPaw21]

@m417z
working on a patch, is there a specific prompt you use to get the report on the Windhawk mods the creators make? i would like to run it myself and spare both of us some work. thank you :)

[m417z]

It's a skill that I maintain, created from past manual reviews and Windhawk knowledge base (API, wiki, existing mods, etc.), running in an environment with the ability to query some of these knowledge base sources. Currently I don't plan on publishing it.

[BlackPaw21]

i see, that is really cool man keep it up.
need to make something similar on my own that is really useful.

[BlackPaw21]

took some time to craft the skill but it sure was worth it. hopefully that is good and doesn't need more tweaking.

[m417z]

A small COM usage issue. I haven't reviewed the other notes.

Submission review

Note: This review was done by Claude, and then refined manually. Due to the amount of submissions, doing a fully manual review for each pull request is no longer feasible. Thank you for understanding.

Please address the following issues. The items in the collapsed sections are optional, so it's your call whether to address them.

---

• CoUninitialize guard should be SUCCEEDED(hrCo), not hrCo == S_OK. CoInitialize/CoInitializeEx returns S_FALSE when the thread was already COM‑initialized, and that call still increments the refcount and must be balanced with CoUninitialize. The new pattern if (hrCo == S_OK) CoUninitialize(); skips the S_FALSE case. This is reachable: GetCurrentVolumePct (line 1953) and SetCurrentDeviceVolume (line 1981) run on the tray thread, which already holds a COM apartment from TrayThreadProc, so their CoInitializeEx returns S_FALSE and the refcount grows by one on every middle‑click / popup volume change. It's harmless in practice (torn down when the thread exits) but incorrect — use if (SUCCEEDED(hrCo)) CoUninitialize(); (that still correctly skips RPC_E_CHANGED_MODE, where init genuinely failed).

Optional improvements

Minor polish — none of this affects users in normal operation, so it's your call.

• A g_stateLock critical section was removed in ToggleMuteCurrentDevice (the per‑device mute branch, around line 1529). Previously the write to g_mutedDeviceId / g_isMutedByUs was under the lock; now it isn't:

  if (ApplyMute(pId, TRUE)) {
      lstrcpynW(g_mutedDeviceId, pId, 512);   // <-- no lock
      g_isMutedByUs = true;
      Wh_SetStringValue(L"MutedDeviceId", pId);
  }

  These fields are read under the lock by RestoreMuteExternal (main thread, on settings change / uninit), so this is a data race — narrow (only when a mute click coincides with a settings change or unload), but re-adding the two lines is free:

  if (ApplyMute(pId, TRUE)) {
      EnterCriticalSection(&g_stateLock);
      lstrcpynW(g_mutedDeviceId, pId, 512);
      g_isMutedByUs = true;
      LeaveCriticalSection(&g_stateLock);
      Wh_SetStringValue(L"MutedDeviceId", pId);
  }

• #include <propvarutil.h> appears unused — no InitPropVariantFrom* / PropVariantTo* helpers are called (the AUMID PROPVARIANT is filled by hand, and PropVariantInit/PropVariantClear come from propidl.h). Safe to drop. (propsys.h for IPropertyStore is a reasonable addition to keep.)

Functionality notes

Non-critical observations about the Persistent Mute feature and the live dashboard refresh — feature behavior, no integration impact.

• Persistent Mute mutes/unmutes every active render endpoint and doesn't remember prior state. ApplyMuteAll sets the OS‑level per‑device mute on all render devices, and un‑toggling calls ApplyMuteAll(FALSE) on all of them. So if a user had independently muted an unrelated device (e.g. via Windows), enabling+disabling Persistent Mute will silently unmute that device against their intent. Since cycling only ever touches the configured swap slots, scoping the mute/unmute to the configured slot device IDs (and/or remembering each device's prior mute state and restoring it) would be more contained and avoid clobbering unrelated devices.

• Turning Persistent Mute off while it is active can leave devices stuck muted. In the all‑mute path g_mutedDeviceId is left empty and MutedDeviceId is persisted as "all". If the user then unchecks Persistent Mute and saves, WM_RELOAD_ALL sets g_persistentMute = FALSE but doesn't unmute anything; the next mute toggle takes the per‑device branch and ApplyMute(nullptr, FALSE) only unmutes the current default device — the others remain muted with g_isMutedByUs now cleared, so the mod no longer tracks them. Consider unmuting‑all when the flag transitions off (e.g. in WM_RELOAD_ALL, if the previous state was muted‑all and persistentMute is now 0, call ApplyMuteAll(FALSE)).

• A device plugged in while persistent‑muted is not muted. ApplyMuteAll is a one‑time snapshot, so a device added afterward plays sound even though the tray shows muted. OnDeviceAdded already fires — muting the new endpoint there (when g_isMutedByUs && g_persistentMute) would keep the state consistent.

• Live dashboard refresh (WM_REFRESH_DEVICE_LIST) has a couple of rough edges when a device event arrives while the dashboard is open:

  • An unsaved, in‑progress combo selection snaps back to the saved value: the repopulate loop overrides newSel whenever s->slots[i].id (the persisted value) matches a device, discarding what the user just picked but hasn't saved.
  • Offline priority entries are dropped. The "(offline)" label appended in WM_CREATE isn't re-added on refresh, and its old index maps to -1, so the combo reverts to "None"; saving after that loses the remembered offline priority device.

  Neither is critical, but they can surprise a user configuring the dashboard while hot‑plugging devices.