ThinkPad E14 Gen 7: no sound from speakers or mic on Windows 10? It's the Windows 11-only audio APOs

TL;DR — On a laptop that ships Windows 11 but was downgraded to Windows 10, the built-in speakers can go completely silent while headphones and USB audio work perfectly. The cause is usually not "the hardware is unsupported." On my ThinkPad E14 Gen 7 the audio driver registers its Dolby APO (Audio Processing Object) COM classes only inside an INF section gated to Windows 11. On Windows 10 that section is skipped, so the audio engine tries to CoCreateInstance an APO that was never registered, fails with REGDB_E_CLASSNOTREG, and the entire speaker stream fails to build — no sound, empty Volume Mixer, "Failed to play test tone." Registering the five missing classes by hand brings the speakers back (clean stereo). Everything below is reproducible with PowerShell, and every claim is backed by an HRESULT or an event-log entry rather than a guess. The same machine's built-in microphone was dead too — a sibling APO bug with the opposite fix; there's a companion section on it near the end.

Tested on

⚠️ Disclaimer. This involves editing HKLM and removing driver packages. It's unofficial and at your own risk. Create a System Restore point first. A full rollback is included at the end. Nothing here touches firmware or hardware.

30-second background: what an APO is

Modern Windows audio runs effects — bass boost, Dolby/DTS, smart-amp speaker protection — as Audio Processing Objects (APOs): COM DLLs the audio engine loads into audiodg.exe and inserts into a per-endpoint processing graph before any audio reaches the device. If the engine can't build that graph for an endpoint, nothing plays on it. Hold onto that: a broken APO doesn't just disable an effect, it can take down the whole endpoint.

The symptom

• Speakers: nothing. No sound at all.
• Headphones (3.5 mm) and USB audio: perfect.
• With Speakers set as the default device, the Volume Mixer shows zero applications — not even System Sounds.
• The Windows "Test" tone fails with "Failed to play test tone."
• Device Manager looks clean — no yellow bangs; every audio device reports This device is working properly.

That last point is what makes it maddening: by every surface-level check, the audio stack is "fine."

The tempting (and wrong) conclusion

This laptop officially ships Windows 11 only. The obvious story writes itself: "Lenovo doesn't validate Windows 10, the smart-amp driver doesn't exist for it, so the speakers physically can't work. Reinstall Windows 11."

That conclusion is unverified — and it turned out to be wrong. "Officially unsupported" means the vendor doesn't test or ship a Win10 driver; it does not mean the hardware can't make sound. And one clue flatly contradicts the pessimistic story: the endpoint enumerates as Speakers (Senary Audio) in the ACTIVE state, and the driver did install. The path is alive. So let's diagnose instead of guessing.

Everything from here to The fix is read-only. Run PowerShell as your normal user for diagnostics.

Step 1 — Confirm the hardware and driver are healthy

Get-CimInstance Win32_SoundDevice |
  Select-Object Name, Manufacturer, Status, ConfigManagerErrorCode | Format-List

Every device reported Status = OK, ConfigManagerErrorCode = 0 — the Senary codec and the Intel SST OED/BUS components. The services run, too:

Get-CimInstance Win32_Service |
  Where-Object DisplayName -match 'Dolby|Senary|Elevoc' |
  Select-Object Name, State, StartMode
# DolbyDAXAPI         Running  Auto
# SenaryAudioApp.Svc  Running  Auto

So the files are installed and the services are running. The problem is higher up the stack — in stream creation, not the driver binding.

Step 2 — Catch the real failure with a WASAPI probe

If the engine can't build an endpoint's APO graph, it can't even resolve the endpoint's shared mix format: IAudioClient::GetMixFormat and Initialize fail, so no app can open a session — which is exactly why the mixer is empty. Let's confirm that directly (full self-contained probe is in the appendix). On the Speakers endpoint:

Speakers GetMixFormat hr=0x80040154   # REGDB_E_CLASSNOTREG

0x80040154 is REGDB_E_CLASSNOTREG — "class not registered." The engine is trying to CoCreateInstance a COM object in the speaker's effect chain, and it isn't registered. For contrast, IsFormatSupported in exclusive mode returned S_OK on the same endpoint — the hardware happily accepts a real PCM format. The wall is software, in the shared-mode effect graph.

Step 3 — Find which APO classes the endpoint uses

The endpoint's effect chain lives in the registry:

$ep = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render'
# 1) find your Speakers endpoint GUID:
Get-ChildItem $ep | ForEach-Object {
  $n = (Get-ItemProperty "$ep\$($_.PSChildName)\Properties" -EA SilentlyContinue).'{a45c254e-df1c-4efd-8020-67d146a850e0},2'
  [PSCustomObject]@{ GUID = $_.PSChildName; Name = $n }
}
# 2) dump its FxProperties (replace <GUID>):
Get-ItemProperty "$ep\<GUID>\FxProperties" | Format-List

In FxProperties, the property keyed {d04e05a6-594b-4fb6-a80d-01af5eed7d1d} holds the APO CLSIDs the engine instantiates. My speakers endpoint referenced four of the driver's Dolby DAX3 wrapper classes (SFX/EFX/OSFX/OMFX); the driver defines a fifth, MFX, that shows up on other endpoints. I registered all five to be safe:

{0EBD8605-17BB-4AE7-AD76-E86F99A425E9}  (SFX  — stream effect)     <- on speakers
{0EBD8607-17BB-4AE7-AD76-E86F99A425E9}  (EFX  — endpoint effect)   <- on speakers
{0EBD8611-17BB-4AE7-AD76-E86F99A425E9}  (OSFX — offload stream effect) <- on speakers
{0EBD8612-17BB-4AE7-AD76-E86F99A425E9}  (OMFX — offload mode effect)   <- on speakers
{0EBD8606-17BB-4AE7-AD76-E86F99A425E9}  (MFX  — mode effect; driver-defined, registered for completeness)

⚠️ These GUIDs are specific to my driver version. Read your own FxProperties. If the layout differs, treat every CLSID-shaped value there as a candidate and test each one in Step 4 — the culprits are whichever aren't registered.

Step 4 — Confirm those classes are not registered

$apo = '0EBD8605-17BB-4AE7-AD76-E86F99A425E9','0EBD8606-17BB-4AE7-AD76-E86F99A425E9',
       '0EBD8607-17BB-4AE7-AD76-E86F99A425E9','0EBD8611-17BB-4AE7-AD76-E86F99A425E9',
       '0EBD8612-17BB-4AE7-AD76-E86F99A425E9'
foreach ($c in $apo) {
  $v = (Get-ItemProperty "HKLM:\SOFTWARE\Classes\CLSID\{$c}\InprocServer32" -EA SilentlyContinue).'(default)'
  '{0}  {1}' -f $c, ($(if ($v) { "-> $v" } else { '*** NOT REGISTERED ***' }))
}

All five came back NOT REGISTERED — no InprocServer32, so CoCreateInstance can only fail. There's the REGDB_E_CLASSNOTREG. Telling contrast: a different APO on the same endpoint (Elevoc, CLSID 001897D5-…) was registered and pointed at a real DLL. Only the Dolby classes were missing. Why?

Step 5 — The smoking gun in the INF

The Dolby APO DLL is present on disk; Windows just never registered it. Find the driver INF and look at how it registers the classes:

$dir = (Get-ChildItem "$env:SystemRoot\System32\DriverStore\FileRepository\dax3_swc_aposvc.inf_amd64_*" -Directory)[0].FullName
Select-String -Path "$dir\dax3_swc_aposvc.inf" -Pattern 'AddReg|APO_AddReg|InProcServer32|DolbyDax3Apo'

The decisive lines:

AddReg = APO_AddReg_Win11
...
[APO_AddReg_Win11]
HKR,Classes\CLSID\%FX_DolbyAPO_WrapperSFX_CLSID_V2%\InProcServer32,,%REG_EXPAND_SZ%,%13%\DolbyDax3Apo.dll
HKR,Classes\CLSID\%FX_DolbyAPO_WrapperSFX_CLSID_V2%\InProcServer32,ThreadingModel,,"Both"
...

The COM-registration block is literally named APO_AddReg_Win11 and only applies on Windows 11. On Windows 10 it is skipped: the device installs, the services start, the DLL is copied — but the five Dolby APO classes are never registered. The Elevoc APO registered fine because its INF isn't gated to Win11.

Root cause, verified end to end

The fix

Do what APO_AddReg_Win11 would have done: register the five CLSIDs against the Dolby APO DLL with ThreadingModel = Both.

First, get the real DLL path (the DriverStore folder hash is machine-specific):

(Get-ChildItem "$env:SystemRoot\System32\DriverStore\FileRepository\dax3_swc_aposvc.inf_amd64_*\DolbyDax3Apo.dll")[0].FullName

Option A — registry file

Save as fix-dolby-apo.reg using your own CLSIDs and DLL path (note the doubled backslashes). Write to HKLM\SOFTWARE\Classes, not HKEY_CLASSES_ROOT: APOs load inside audiodg.exe (a system service), so the registration must be machine-wide.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8605-17BB-4AE7-AD76-E86F99A425E9}\InprocServer32]
@="C:\\Windows\\System32\\DriverStore\\FileRepository\\dax3_swc_aposvc.inf_amd64_2d43ea2009b9f4a0\\DolbyDax3Apo.dll"
"ThreadingModel"="Both"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8606-17BB-4AE7-AD76-E86F99A425E9}\InprocServer32]
@="C:\\Windows\\System32\\DriverStore\\FileRepository\\dax3_swc_aposvc.inf_amd64_2d43ea2009b9f4a0\\DolbyDax3Apo.dll"
"ThreadingModel"="Both"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8607-17BB-4AE7-AD76-E86F99A425E9}\InprocServer32]
@="C:\\Windows\\System32\\DriverStore\\FileRepository\\dax3_swc_aposvc.inf_amd64_2d43ea2009b9f4a0\\DolbyDax3Apo.dll"
"ThreadingModel"="Both"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8611-17BB-4AE7-AD76-E86F99A425E9}\InprocServer32]
@="C:\\Windows\\System32\\DriverStore\\FileRepository\\dax3_swc_aposvc.inf_amd64_2d43ea2009b9f4a0\\DolbyDax3Apo.dll"
"ThreadingModel"="Both"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8612-17BB-4AE7-AD76-E86F99A425E9}\InprocServer32]
@="C:\\Windows\\System32\\DriverStore\\FileRepository\\dax3_swc_aposvc.inf_amd64_2d43ea2009b9f4a0\\DolbyDax3Apo.dll"
"ThreadingModel"="Both"

Merge it elevated (right-click → Merge → accept UAC), then restart the audio engine from an elevated prompt:

Restart-Service Audiosrv -Force

Option B — PowerShell (auto-detects the DLL path)

#requires -RunAsAdministrator
$dll = (Get-ChildItem "$env:SystemRoot\System32\DriverStore\FileRepository\dax3_swc_aposvc.inf_amd64_*\DolbyDax3Apo.dll")[0].FullName
$apo = '0EBD8605-17BB-4AE7-AD76-E86F99A425E9','0EBD8606-17BB-4AE7-AD76-E86F99A425E9',
       '0EBD8607-17BB-4AE7-AD76-E86F99A425E9','0EBD8611-17BB-4AE7-AD76-E86F99A425E9',
       '0EBD8612-17BB-4AE7-AD76-E86F99A425E9'
foreach ($c in $apo) {
  $k = "HKLM:\SOFTWARE\Classes\CLSID\{$c}\InprocServer32"
  New-Item $k -Force | Out-Null
  New-ItemProperty $k -Name '(default)'       -Value $dll  -PropertyType String -Force | Out-Null
  New-ItemProperty $k -Name 'ThreadingModel'  -Value 'Both' -PropertyType String -Force | Out-Null
}
Restart-Service Audiosrv -Force

Then Settings → System → Sound → set "Speakers (Senary Audio)" as the output device and play something. Still silent? Reboot once — the registration is picked up cleanly on a fresh start.

Verify it worked

Re-run the WASAPI probe; the failure is gone:

Speakers GetMixFormat   = 0x00000000   # S_OK  -> the stream graph builds
Speakers SHARED Initialize = 0x00000000 # the shared stream opens -> apps can play

The Volume Mixer immediately starts listing applications again, and — the real test — the speakers play.

The one setting to leave OFF — and why (with proof)

Keep Speaker Properties → Advanced → Signal Enhancements → "Enable audio enhancements" unchecked. With it off, the speakers play clean stereo. Turn it on and they go silent again until you turn it back off.

I chased why, because "it just doesn't work on Win10" is exactly the hand-wave this post argues against. Comparing the Speakers and Headphones endpoints under …\MMDevices\Audio\Render\{guid}\FxProperties:

• Both endpoints reference the same Dolby APO classes (now registered) and the same Elevoc APO.
• The headphones endpoint plays fine with enhancements on — so the Dolby APO is not fundamentally incompatible with Windows 10. It runs.
• The difference: the speakers endpoint has extra ,100 values binding each Dolby APO instance to the DAX3 APO service device (SWD\DRIVERENUM\{…}#DOLBYAPO_DAX3APOSVC). The headphones endpoint has no such binding.

So enabling enhancements on the speakers activates the service-backed Dolby processing (speaker tuning + smart-amp), and that initialization is what fails. The proof is in the Application event log — the instant enhancements go on, audiodg.exe crashes in a tight loop:

Faulting application name: AUDIODG.EXE
Faulting module name: KERNELBASE.dll
Exception code: 0xe06d7363        # SEH code for an unhandled C++ exception

The engine loads the Dolby APO into audiodg, the APO throws, audiodg dies, Windows restarts it, it reloads the APO, it throws again — hence media apps reporting "can't play audio, restart your PC." The headphones path never loads that service-bound APO, so it never crashes. (Watch it live: Event Viewer → Windows Logs → Application, filter to Application Error, while toggling the checkbox.)

Because the vendor effect chain — which includes smart-amp speaker-protection processing — is bypassed in this configuration, don't run the speakers at maximum volume for extended periods.

What I ruled out (so you don't have to)

Enterprise debugging is as much about eliminating hypotheses as confirming them. Things I tested and discarded, with evidence:

• "The APO metadata is missing." The same Win11 INF section also writes APO metadata under AudioEngine\AudioProcessingObjects (Microsoft's APO docs confirm an Apo_AddReg section registers in two places). I replicated it exactly — FriendlyName, Flags=0xc, connection counts, APOInterface0 — for all five wrappers. Enhancements still crashed audiodg. Not the blocker (and the working Elevoc APO has no such metadata at all).
• "Wrong / mismatched driver." I'd installed several driver packages while troubleshooting. I verified the bound set is consistent: Intel SST 20.40.12690.2 on every SST device, and DolbyDax3Apo.dll + DAX3API.exe both 3.30811.890.0. There was no version skew and no duplicate Dolby package in the DriverStore.
• Stale driver packages. pnputil /enum-drivers revealed three leftover Intel SST packages (including an ancient 10.23.0.3586 from 2020) — all unbound. I removed them with pnputil /delete-driver oemNN.inf (no /force, which refuses if a package is in use). Good hygiene; no effect on the crash. Worth knowing it wasn't the cause.

Net: the crash is an APO-level runtime incompatibility inside a closed-source Dolby DLL, not a registry, metadata, or driver-version gap. Pinning down the exact throw would need a crash dump with Dolby's private symbols, which won't change the outcome.

What I couldn't fix

Full Dolby speaker post-processing is not reachable on Windows 10 here. The service-backed APO crashes audiodg, and that's the genuine boundary the OEM's Windows 11 validation sits behind. The shipped, stable result: working speakers in clean stereo, enhancements off. Honest beats optimistic.

Rollback

Remove the keys and restart audio:

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8605-17BB-4AE7-AD76-E86F99A425E9}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8606-17BB-4AE7-AD76-E86F99A425E9}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8607-17BB-4AE7-AD76-E86F99A425E9}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8611-17BB-4AE7-AD76-E86F99A425E9}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8612-17BB-4AE7-AD76-E86F99A425E9}]

You're never worse off than the original "no sound" state.

Make it work on your machine

The exact GUIDs, DLL, and INF differ per vendor and driver version, but the method generalizes:

1. Probe the Speakers endpoint with WASAPI. If GetMixFormat returns 0x80040154, you have this class of bug.
2. Read the endpoint's FxProperties → key {d04e05a6-594b-4fb6-a80d-01af5eed7d1d} for the APO CLSIDs.
3. Check each under HKLM:\SOFTWARE\Classes\CLSID\{…}\InprocServer32. Missing ones are your culprits.
4. Find the owning driver in DriverStore\FileRepository and Select-String its INF for an AddReg section that's OS-gated (look for Win11, a build decoration, or an unapplied section). It names the DLL and ThreadingModel to register.
5. Register the missing CLSIDs against that DLL and Restart-Service Audiosrv.

This pattern shows up on many "Windows 11-only" laptops force-installed with Windows 10, and occasionally after Windows Update swaps an audio driver. Realtek / Conexant / Synaptics codecs paired with Dolby / DTS / Waves / Nahimic APO stacks are all candidates.

Companion case: the microphone — same crash, the opposite fix

After the speakers, the built-in microphone turned out to be dead too — and it's the same audiodg crash wearing a different mask, with a fix that's the mirror image of the speaker one.

Symptom: the internal mic array captures nothing; a 3.5 mm headset mic or a USB mic works fine.

Probe (capture side — EnumAudioEndpoints with dataFlow = eCapture):

Microphone Array  GetMixFormat = 0x00000000      # format resolves fine...
Microphone Array  Initialize   = 0x800706BE      # ...but RPC_S_CALL_FAILED

GetMixFormat succeeding — unlike the speakers' REGDB_E_CLASSNOTREG — means the capture APO classes are registered. The 0x800706BE (RPC_S_CALL_FAILED) on Initialize is the tell: the RPC channel to audiodg dropped mid-call, because audiodg crashed. The Application log confirms the same 0xe06d7363 C++ exception — this time thrown by the Elevoc AI noise-suppression capture APO as it initializes on the mic stream. Same family as the speakers' "enhancements on" crash, opposite registration state.

Why the speaker fix doesn't transfer. The Dolby case was a missing class — you add it. Here the Elevoc class is present and loads, then throws at runtime. Worse, every endpoint-level workaround failed to stick: turning off "audio enhancements", deleting the APO from the endpoint's FxProperties, even stopping the Elevoc service — the driver re-applies the effect chain on every audio restart. And there's no Win10 driver to fall back to: Lenovo ships only Windows 11 audio drivers for this model, Windows Update offers no audio driver, and copying the correct per-codec config into System32\ElevocConfig didn't stop the crash. (Elevoc does build Win10 APOs — they ship on older models — but only as GNA-era builds for those platforms' codecs, with no models for this machine. So the APO isn't inherently Win10-hostile; there just isn't a build that fits this hardware.)

The fix: remove the layer. Since the crash is the Elevoc APO itself and it's driver-enforced, take Elevoc out of the capture path at the driver level so the mic falls back to raw Intel SST capture:

# elevated. Find the oemNN.inf publish names first:
pnputil /enum-drivers     # locate: elevocapo64.inf, elevocapo64ext.inf, intcdmicext_e.inf
# then remove each (this uninstalls from the device and deletes the package):
pnputil /delete-driver oemNN.inf /uninstall /force
Restart-Service Audiosrv -Force      # then reboot to finish

Re-probe:

Microphone Array  GetMixFormat = 0x00000000
Microphone Array  Initialize   = 0x00000000   # stream opens; audiodg stable, 0 crashes

The mic now works — raw, without Elevoc's AI noise-suppression, which is a fair trade for a microphone that exists. Reversible: reinstalling the vendor "Audio Driver" bundle restores Elevoc (and the crash). If you need the AI processing, its only fully-supported home on this hardware is Windows 11.

The symmetry worth remembering: one endpoint failed because a needed APO was missing → register it; the other failed because a present APO was incompatible → remove it. Same audiodg, opposite remedies — and the WASAPI HRESULT told you which was which (REGDB_E_CLASSNOTREG vs a crash-induced RPC_S_CALL_FAILED) before you changed a thing.

Key takeaways

• "Officially unsupported" is a support policy, not a law of physics. Verify before you conclude.
• A broken APO can silence an entire endpoint — render or capture — not just an effect, because the engine can't build the processing graph.
• The HRESULT names the failure mode: REGDB_E_CLASSNOTREG = a needed APO isn't registered (add it); a crash-induced RPC_S_CALL_FAILED with audiodg faulting 0xe06d7363 = a present APO is incompatible and throws (remove it). Opposite diagnoses, opposite fixes.
• Register APOs under HKLM\SOFTWARE\Classes\CLSID (machine-wide) — audiodg.exe is a service and won't see per-user HKCU classes.
• Endpoint-level edits (FxProperties, "disable enhancements") don't stick if the vendor driver re-applies the effect chain — for those, you act at the driver level (pnputil /delete-driver).
• Let the event log and HRESULTs carry the argument. Every step here was a code, not a hunch — including the parts that say "this can't be fixed."

Appendix: the WASAPI probe

Self-contained; run as your normal user. It finds the Speakers endpoint and reports GetMixFormat (and, after the fix, the shared-mode Initialize).

$cs = @'
using System; using System.Runtime.InteropServices;
public static class P {
  [ComImport, Guid("BCDE0395-E52F-467C-8E3D-C4579291692E")] class E {}
  [Guid("A95664D2-9614-4F35-A746-DE8DB63617E6"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  interface IE { [PreserveSig] int EnumAudioEndpoints(int f,int m,out IC c); [PreserveSig] int GetDefaultAudioEndpoint(int f,int r,out ID d); }
  [Guid("0BD7A1BE-7A1A-44DB-8397-CC5392387B5E"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  interface IC { [PreserveSig] int GetCount(out int c); [PreserveSig] int Item(int i,out ID d); }
  [Guid("D666063F-1587-4E43-81F1-B948E807363F"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  interface ID { [PreserveSig] int Activate(ref Guid i,int x,IntPtr p,[MarshalAs(UnmanagedType.IUnknown)] out object o);
    [PreserveSig] int OpenPropertyStore(int a,out IP ps); [PreserveSig] int GetId([MarshalAs(UnmanagedType.LPWStr)] out string s); [PreserveSig] int GetState(out int s); }
  [Guid("886d8eeb-8cf2-4446-8d02-cdba1dbdcf99"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  interface IP { [PreserveSig] int GetCount(out int c); [PreserveSig] int GetAt(int i,out PK k); [PreserveSig] int GetValue(ref PK k,out PV v); }
  [StructLayout(LayoutKind.Sequential)] struct PK { public Guid f; public int pid; }
  [StructLayout(LayoutKind.Explicit)] struct PV { [FieldOffset(0)] public short vt; [FieldOffset(8)] public IntPtr p; }
  [Guid("1CB9AD4C-DBFA-4c32-B178-C2F568A703B2"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  interface IAC { [PreserveSig] int Initialize(int s,int f,long d,long p,IntPtr fmt,IntPtr g); [PreserveSig] int GetBufferSize(out uint n);
    [PreserveSig] int GetStreamLatency(out long l); [PreserveSig] int GetCurrentPadding(out uint n);
    [PreserveSig] int IsFormatSupported(int s,IntPtr f,out IntPtr c); [PreserveSig] int GetMixFormat(out IntPtr f); }
  static string Nm(ID d){ IP ps; if(d.OpenPropertyStore(0,out ps)!=0)return "?";
    var k=new PK{f=new Guid("a45c254e-df1c-4efd-8020-67d146a850e0"),pid=14}; PV v;
    if(ps.GetValue(ref k,out v)!=0||v.p==IntPtr.Zero)return "?"; return Marshal.PtrToStringUni(v.p); }
  public static string Run(){ var en=(IE)(new E()); IC col; en.EnumAudioEndpoints(0,1,out col); int n; col.GetCount(out n);
    for(int i=0;i<n;i++){ ID d; col.Item(i,out d); var nm=Nm(d); if(nm!=null&&nm.StartsWith("Speakers")){
      var iid=new Guid("1CB9AD4C-DBFA-4c32-B178-C2F568A703B2"); object o; d.Activate(ref iid,1,IntPtr.Zero,out o);
      var c=(IAC)o; IntPtr f; int hr=c.GetMixFormat(out f); int sh=-1; if(hr==0) sh=c.Initialize(0,0,10000000,0,f,IntPtr.Zero);
      return "Speakers GetMixFormat=0x"+hr.ToString("X8")+"  SHARED Initialize=0x"+sh.ToString("X8"); } }
    return "No active Speakers endpoint found"; }
}
'@
Add-Type -TypeDefinition $cs -Language CSharp
[P]::Run()

To probe the microphone instead, change EnumAudioEndpoints(0, …) to EnumAudioEndpoints(1, …) (eCapture) and match "Microphone" instead of "Speakers".

Found this useful, or hit a variant on a different machine? Drop your codec + APO stack and the GetMixFormat HRESULT in the comments — the method in "Make it work on your machine" should map across vendors.