Problems with Native Audio SDK on x86 UWP builds

Unity Engine
,
1

I am currently running into problems using the Unity Native Audio SDK on a Universal Windows Platform x86 build. My goal is to develop a Unity audio plugin for use on the Microsoft Hololens, but the issue I am having is present when building a UWP app to my own PC so I am using that as a starting point.

Using the most recent version of the Native Audio SDK (API version 0x010402) and Unity (version 2017.4.3f1) I can compile the project into a UWP build, but only after adjusting the x86_64 plugin settings so that it is set to a x64 CPU. Without this change the plugin settings collide and the project will not compile. From Visual Studio (version 15.8.5) I then compile debug and release versions of the x64 version without issue and can cycle through all the different demo scenes and clearly hear the audio effects.

However, when compiling for x86 the debug version throws the error “Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call.“ This is similar to the issue described here: https://fogbugz.unity3d.com/default.asp?1028151_94fmv154sdg2cu8e

In that post, it is suggested that the compiler define “PLATFORM_WINRT” needs to be used to switch “AUDIO_CALLING_CONVENTION” to _stdcall. I therefore setup a new WSA version of the plugin and place it in the folder …/Plugins/WSA/x86 with the appropriate settings for the plugin to ensure it is used in the UWP build. Note that to avoid a compiler error, I also need to update line 411 of AudioPluginUtil.cpp to match the definition of UnityGetAudioEffectDefinitions() defined on line 292 of AudioPluginInterface.h.

The resulting build avoids the earlier Run-Time Check Failure, but now the audio effects don’t seem to be registering properly in Unity. For instance, when I click on the Wah-Wah example, I get the following error message:

“Audio effect Demo WahWah could not be found. Check that the project contains the correct native audio plugin libraries and that the importer settings are set up correctly.”

At this point, I am unsure how to proceed since I cannot get the base Native Audio SDK code to function on my desired platform and thus any further work on my plugin would be meaningless. Am I missing a setting that is necessary to get the effects visible to Unity in this build configuration?

I am hoping that I am making a basic mistake in setting up the Native Audio SDK for a UWP x86 build since I would be surprised if no one else previously encountered this error.

Any help anyone could provide would be immensely appreciated! Thank you!

2

Does anyone have any advice for getting the Unity Native Audio SDK functioning on a UWP x86 build?

I am unsure how to proceed with my project if the SDK examples don’t even compile and function properly for my target platform. If the community doesn’t have any guidance for this problem, then perhaps it is a bug in the SDK that has not been encountered before and I will probably just end up filing a bug report.

Thanks for any help resolving this issue!

3

Hey, the bug report you filled just got into our grabbag. Sorry for the delayed response - I usually don’t read this forum section.

It seems like you’re a victim of name mangling. When you specify “__stdcall” calling convention, the linker will automatically mangle the function name unless you tell it not to. And that’s indeed what seems to have happened. From your repro project:

E:\Downloads\DefaultLocation\case_1093464-NativeAudioSDK_UWPbugreport\Assets\Plugins\WSA\x86>dumpbin /exports AudioPluginDemo.dll
Microsoft (R) COFF/PE Dumper Version 14.15.26729.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file AudioPluginDemo.dll

File Type: DLL

  Section contains the following exports for AudioPluginDemo_WSA_WindowsRuntimeComponent.dll

    00000000 characteristics
    FFFFFFFF time date stamp
        0.00 version
           1 ordinal base
           4 number of functions
           4 number of names

    ordinal hint RVA      name

          1    0 0001116D DllCanUnloadNow
          2    1 000111C7 DllGetActivationFactory
          3    2 0001148D _GetInteger@0
          4    3 00011226 _UnityGetAudioEffectDefinitions@4

You can force no mangling by adding a module definition file and specify export name manually. We have a native graphics plugin example here that shows how to do it:

https://bitbucket.org/Unity-Technologies/graphicsdemos/src/364ac57cea5c197ca9b7015ba29dcc1ff94c9f61/NativeRenderingPlugin/PluginSource/source/RenderingPlugin.def?at=default&fileviewer=file-view-default

Let me know if you have more questions :).

By the way: thanks for the bug report. We will fix the sample.

2 Likes
4

Just was just able to successfully deploy my custom audio plugin to my HoloLens and this seems to have fixed the issue! Thank you so much for your help!

I am interested in exploring the purpose of function name mangling since that seems like a very counter intuitive approach for a programmer learning a new system. Having a starting point SDK that compiles and deploys appropriately to my desired platform is a huge leap forward for my research.

Just a reminder that if you or another team are reviewing the Native Audio SDK code it would also help to update line 411 of AudioPluginUtil.cpp as given in my original post. I also think including the UWP version of the project in the Visual Studio solution would go a long way since a forum post from last year indicates I’m not the only person running into problems getting the Native Audio SDK working on the HoloLens ( "Run-Time Check Failure #0-The value of ESP was not properly saved across a function call" in Plugin ).

Thanks again!

1 Like
5

Yeah, will do.