Drop NAudio.CoreAudioApi dependency (or wait for upstream ComWrappers support)

[hoobio]

Problem

Earmark.Audio uses NAudio.CoreAudioApi for Core Audio device + session enumeration and change events:

• MMDeviceEnumerator, MMDevice, DataFlow, DeviceState, Role (device introspection / default-device queries) - src/Earmark.Audio/Services/AudioEndpointService.cs.
• AudioSessionManager, AudioSessionControl, IAudioSessionEventsHandler, AudioSessionState (per-session listing + change events) - src/Earmark.Audio/Services/AudioSessionService.cs.
• IMMNotificationClient (device add/remove/default-changed events).

NAudio's COM interface declarations are classic [InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]. Marshalling those depends on System.StubHelpers.InterfaceMarshaler in CoreLib, which the .NET 10 trimmer feature-switches out and prints IL2026: Built-in COM support is not trim compatible. PR #19 confirmed the runtime then throws TypeLoadException on the first MMDeviceEnumerator constructor call. This blocks the trimming follow-up in #21 alongside the own-code migration in #22.

Pairs with #22: even if our own COM declarations are migrated to [GeneratedComInterface], NAudio's classic-COM declarations would still keep System.StubHelpers.InterfaceMarshaler reachable and the trimmer would still strip it.

Proposed Solution

Two paths, in priority order:

1. Wait for NAudio to support ComWrappers upstream (filed as a tracking issue at NAudio.CoreAudioApi (WASAPI) breaks under PublishTrimmed: classic-COM stripped by .NET trimmer naudio/NAudio#1256, referencing the existing dormant directsound playback breaks with trimming enabled naudio/NAudio#1191 about DirectSound + trimming). NAudio.Wasapi 2.2.1 currently targets netstandard2.0 + UAP10.0.18362, so an upstream migration would have to multi-target net8.0+ to get [GeneratedComInterface]. Slow path, depends on upstream maintainer bandwidth.
2. Replace the NAudio surface we use with hand-rolled [GeneratedComInterface] declarations. Roughly five COM interfaces plus IID/HResult/PROPVARIANT plumbing (the same pattern Migrate own classic-COM interop to ComWrappers (IPolicyConfigVista, IAudioPolicyConfigFactory) #22 establishes for our existing interop). Once Migrate own classic-COM interop to ComWrappers (IPolicyConfigVista, IAudioPolicyConfigFactory) #22 lands, Earmark.Audio already has the ComWrappers strategy class and the helpers needed to do this in-tree.

Recommendation: start path 1 (cost of one upstream issue), but plan on path 2 for actually unblocking #21 since upstream timing is uncertain.

Alternatives Considered

• Fork NAudio.Wasapi. Possible but creates ongoing maintenance debt for ~120 KB of binaries.
• Skip the NAudio side entirely and accept that trimming is permanently disabled. That's the current state; PR perf(installer): shrink MSI size #19 documents the inline reasoning. Costs the ~30-50% additional MSI reduction expected from Enable PublishTrimmed for Release builds #21.

Additional Context

• Pairs with Migrate own classic-COM interop to ComWrappers (IPolicyConfigVista, IAudioPolicyConfigFactory) #22; both must land before Enable PublishTrimmed for Release builds #21 can be tackled.
• The remaining NAudio.Core + NAudio.Wasapi together are ~120 KB on disk, so the direct size payoff of dropping them is negligible. The win comes from unblocking trimming.
• Related upstream context: directsound playback breaks with trimming enabled naudio/NAudio#1191 (open since 2024, no maintainer response, OP gave up and moved to SDL).

Checklist

• I searched existing issues and this hasn't been requested yet