WINUI 3 & Microsoft GS Synth

[Cal63]

I'm having problems getting sound out of this device when using WINUI 3.

Other people have reported that they had the same problem under UWP, but that was fixed when they referenced the MS General Midi dls.

I'd asked the question previously here:

https://docs.microsoft.com/en-us/answers/questions/762823/winui-3-and-ms-general-midi.html

As you can see, the device works with unpackaged apps, but not packaged ones

Any help appreciated.

Thanks

[zhangyufei49]

Have you found a solution? I've also encountered this problem.

[DarranRowe]

Referencing the General Midi Extension SDK doesn't work?

This works perfectly fine for me.

[DarranRowe]

As a long winded description as to what is going on and what is needed to fix it. The problem is centered around loading the General Midi instrument database.

For an unpackaged desktop application, the application is able to read the database directly out of C:\Windows\System32\drivers or C:\Windows\SysWoW64\Drivers (assuming the system drive is C). When running the application as unpackaged, calling midiOutOpen triggers the loading of the database, and this is visible in Process Monitor.

If the application is packaged, then, for some reason, the application never reads this copy of the database and Process Monitor shows no attempt to read any instrument database. The call to midiOutOpen fails with a return of an unspecified error and so this midi device does not work. By referencing the Microsoft.Midi.GmDls package, the instrument database is placed in an alternative location that Windows will search.

The instrument database is loaded from the package here, and the application is packaged. In this case, the application plays back midi output without issue.

Now, I am making the huge assumption here that failure to get sound out of Microsoft GS Wavetable Synth is being caused by midiOutOpen failing due to gm.dls not being read. If you are having a different problem, then the following steps may not apply.

Anyway, the fix to get a packaged application to load gm.dls is to get the project that packages the application to reference the Microsoft.Midi.GmDls Extension SDK. This is can be awkward due to how the Extension SDKs work. The first thing to check is whether or not the Extension SDK is installed. This requires installing the Windows SDK. The Windows SDK is a different package to the Windows App SDK.

To verify that the Windows SDK is installed on the system, check the Visual Studio Installer. These can be found under the Desktop development with c++ workload or the WinUI application development workload.

The Windows 11 SDK (version) and Windows 10 SDK (version) are the relevant options. The WinUI application development workload would be the one you would most likely choose if you are developing for C#. You can verify that the Windows SDK is installed by checking C:\Program Files (x86)\Windows Kits\10 to see if it exists. Also check under Platforms\UAP in the Windows SDK directory to be sure that the version that matches the Windows version that you wish to target is installed. After this, check C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs. This should contain the Microsoft.Midi.GmDls directory. If everything exists then placing:

  <ItemGroup>
    <SDKReference Include="Microsoft.Midi.GmDls, Version=$(TargetPlatformVersion)">
      <Name>Microsoft General MIDI GLS for Universal Windows Apps</Name>
    </SDKReference>
  </ItemGroup>

in your .wapproj, if you have a separate packaging project, or the .vcxproj/.csproj, if your application is packaged but you don't have a separate packaging project, is all that should be needed in order to make things work. Unfortunately, manually editing the project file is needed due to how the project system works. This should cause the project system to add a PackageDependency for the Microsoft.Midi.GmDls package in the AppxManifest.xml file.

If your packaged application isn't being installed through the Microsoft Store, be aware that you will have to install the Microsoft.Midi.GmDls package since your application would now depend on it. You can find the redistributable for this package in the Extension SDK directory, it is named MidiVoices.appx.

[zhangyufei49]

Thank you so much! I followed the detailed steps you gave me and was able to identify the root cause of my problem and solve it successfully. Thank you!😘😘😘

[Tony-Pappas]

Thank you Darran! Your answer should be marked as the solution, it works! 👍

[riverar]

The root cause is that wdmaud.drv!CMicrosoftGSWavetableSynth::LoadDLSFile uses identity as the sole criterion for determining application type, which is an incorrect assumption today. (To be fair, only "UWP" apps had identity back when this code was probably written.) Applications possessing identity, irrespective of their packaging method or AppContainer status, will bypass the disk-based General MIDI instrument database and default to the Microsoft.Midi.GmDls framework package instead. There's no fallback capability.

If you're looking to avoid the framework package, one approach would be to get in the middle of the identity check. For example, you could hook (e.g., manually, MSIX PSF, etc.) RtlCompareUnicodeString in your app and return 1 in scenarios where the source string is WIN://SYSAPPID. I've tested this personally and it works. Alternatively, you could hook NtQueryInformationToken(..., TokenSecurityAttributes, ...) and strip out the claim in your token. And another alternative would be to just patch wdmaud.drv directly in memory.