Add ignorelist for audio sources.

[sleepcompiler]

Summary

Adds an Ignored Audio Sources list that lets users hide specific apps from the Volume Mixer flyout, media flyout, and taskbar widget at the same time.

Users can add sources either by selecting from currently active audio sessions or by entering an app name manually. The list is persisted across restarts.

Motivation

The current media surfaces can sometimes pick up temporary audio sessions, such as browser tabs with auto-playing videos or background content the user never intentionally started.

Previously, the only way to filter these was through the existing App Filtering system, which is mode-based and only applies to the media flyout.

This adds a separate always-on ignore list for cases where a user simply never wants a specific app to appear anywhere.

Type of Change

• Feature
• Bug fix
• Refactor (no functional changes)
• Style (formatting, naming)
• Other

What Changed

UserSettings.cs

Added IgnoredAudioSources as an ObservableCollection.
Persisted it alongside the existing app filtering settings.
Kept it separate from BlockedApps/AllowedApps since the behaviour is different.

MainWindow.xaml.cs

Added an IgnoredAudioSources check at the start of IsSessionAllowed().
This makes ignored sources apply regardless of App Filtering being enabled.
Since this is the shared check, it covers media flyout, taskbar widget, and Next Up flyout.

VolumeMixerViewModel.cs

Added filtering for ignored sources inside RefreshSessions().
Subscribed to collection changes so updates apply immediately without restarting.
Added cleanup in Dispose().

VolumeMixerPage.xaml

Added an "Ignored Audio Sources" section to the Volume Mixer settings page.
Includes:
Dropdown for active audio sessions
List of ignored sources
Remove buttons
Manual app name input

VolumeMixerPage.xaml.cs

Added handlers for adding/removing ignored sources.
Added SaveAndRefresh() to save settings and immediately refresh media surfaces.

Dictionary-en-US.xaml

Added localisation keys for the new settings UI.

Additional Information

Why not reuse BlockedApps?

BlockedApps is tied to the existing App Filtering system and only applies when filtering is enabled.

IgnoredAudioSources is intended to be a separate, always-active list:

"Never show this app anywhere"
vs.
"Apply this filter rule when filtering is enabled"

It also covers both SMTC sessions and WASAPI sessions.

Checklist

• Code changes are manually tested and working.
• Formatting and naming are consistent with the project.
• Self-review of changes is done.

• AI tools were used (if yes, I reviewed and fully understand the changes myself).

[GXTVV]

Could add option to hide specific website? Like only block audio from (https://www.instagram.com/)?

[unchihugo]

Hi @sleepcompiler, thank you for looking to contribute. I'm a bit confused about what this PR is trying to achieve -- the description claims some things that aren't right:

The current media surfaces can sometimes pick up temporary audio sessions, such as browser tabs with auto-playing videos or background content the user never intentionally started.

Previously, the only way to filter these was through the existing App Filtering system, which is mode-based and only applies to the media flyout.

The filters do apply to everything that consumes from the SMTC API, not just the media flyout.

IgnoredAudioSources is intended to be a separate, always-active list:

"Never show this app anywhere"
vs.
"Apply this filter rule when filtering is enabled"

The app filters do the same thing - all consumers of the SMTC API read from the filter list (media flyout, taskbar widget, next up)

Also, your screenshot shows the app filtering page, but with an item in the list that's a string of random characters. I'm not sure what that is, and the average user would definitely not know either. Could you elaborate on that?

[sleepcompiler]

Hello, and first of all let me apologize for this disaster of a PR. I made gemini generate the text and it used the git logs to look at changes made and drafted the PR using the provided template.

You're right, the existing App Filtering system does apply to all SMTC consumers, not just the media flyout.

The only real new part of this PR is the Volume Mixer filtering: the mixer uses WASAPI AudioSessionControl objects (via NAudio), which is a completely separate API that the existing SMTC-based filtering never touches. A user who blocks Chrome in App Filtering will still see Chrome in the expanded Volume Mixer panel.

The IgnoredAudioSources list and the additions to IsSessionAllowed() may be redundant given that BlockedApps already works everywhere. Would you prefer I:

1. Revert the SMTC-side changes and simply reuse BlockedApps to also filter WASAPI sessions in the mixer?
2. Or keep a separate list if you'd prefer the mixer filtering to be independent of the mode-based App Filtering toggle?

Also regarding the screenshot: That was intended for a separate issue. That is what my browser shows up as on the filtering page. Other apps show up fine. I submitted the PR at 3 AM-ish and mixed up the attachments. Apologies.
Here's the real media:

Screen.Recording.2026-06-29.024458.mp4

[sleepcompiler]

Could add option to hide specific website? Like only block audio from (https://www.instagram.com/)?

Windows WASAPI (the audio API used by the Volume Mixer) has no knowledge of browser tabs. Chrome, Edge, and Firefox pool all tab audio into the same process. There is literally no API surface — not WASAPI, not COM, not Win32 — that can separate youtube.com from twitch.tv at the audio session level. This would require a browser extension to bridge that gap.