[BUG]: Opening a MIDI connection raises the client application's process priority class to HIGH (MidiXProc MMCSS fallback)

This came up when working on message scheduling.

Everything below the break is via GitHub Copilot (Claude Opus 5)

Pete
Microsoft

Problem

EnableMmcss (MidiXProc.cpp, ~L187) takes an else branch when MMCSS is disabled, and MMCSS is off by default — MIDI_USE_MMCSS_REG_DEFAULT_VALUE is 0x00000000 (MidiDefs.h L107), keyed on HKLM\SOFTWARE\Microsoft\Windows MIDI Services\UseMMCSS. That branch is:

SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS);
SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);

SetPriorityClass affects the whole process, and CMidiXProc runs inside client processes too (the cross-process queue behind Midi2MidiSrvTransport), not just midisrv. It's called from CMidiXProc::MidiInWorker (L1320).

It is also never undone: DisableMmcss only resets the MMCSS handle and does nothing at all when MMCSS is disabled, so the elevated priority class persists for the life of the application.

REALTIME_PRIORITY_CLASS fails without SeIncreaseBasePriorityPrivilege, leaving HIGH. An application that holds that privilege would get REALTIME — not tested.

Steps to reproduce

1. Confirm MMCSS is at its default: HKLM\SOFTWARE\Microsoft\Windows MIDI Services\UseMMCSS absent or 0.
2. Note a normal process's base priority: (Get-Counter '\Process(pwsh)\Priority Base').CounterSamples[0].CookedValue → 8
3. Open a MIDI connection and sample the client:

   midi.exe endpoint send-message --endpoint-id "<loopback A id>" 0x21234567 `
       --count 600 --delay 20 --offset-microseconds 500000 --no-wait
   Get-Counter '\Process(midi)\Priority Base' -SampleInterval 1 -MaxSamples 5
   

Expected: client stays at NORMAL (8).
Actual: 13 (HIGH), on all 5 samples.

Suggested fix direction

Drop the process-wide calls from the fallback and keep only SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL), which is priority 15 in both NORMAL and HIGH classes — so the worker thread's scheduling is unchanged while the host process is left alone. Libs/MidiXProc is shipping, so this needs a KIR.

Precedent: the same pattern was just removed from the outbound scheduler under Feature_Servicing_MIDI2SchedulerV2, where it was costing midisrv a full core per endpoint.

Start in Libs/MidiXProc/MidiXProc.cpp at EnableMmcss around line 187 and its call from CMidiXProc::MidiInWorker around line 1320; check MidiDefs.h around line 107 for the default. Compare the Feature_Servicing_MIDI2SchedulerV2 precedent, then reproduce the PowerShell priority-counter steps to verify the client remains at NORMAL while the worker scheduling behavior is retained.