Audacity, ASIO & misbehaving 'Realtek ASIO' driver

Hi all,

I’m wanting to build a version of Audacity on WIndows 10 to use the ASIO devices interface. I followed the instructions in the win\build.txt document in the Audacity distribution from git. Compiled the wxWidgets DLL, downloaded the ASIO SDK, set (and verified) the ASIOSDK_DIR and WXWIN environment variables. Compilation succeeded.

However, after moving the compiled Audacity.exe executable into the C:\Program Files (x86)\Audacity installation folder and launching it I am immediately greeted with a dialog box containing the following text:

Mismatch between the program and library build versions detected.
The library used 3.1.1 (wchar_t,Visual C++ 1900,wx containers),
and your program used 3.1.1 (wchar_t,Visual C++ 1900,wx containers,compatible with 3.0).

This is more than a bit cryptic to my inexperienced eyes. Furthermore, I’m confused as to why there would be a mismatch, since the error dialog states a mismatch between library “library used 3.1.1 (wchar_t,Visual C++ 1900,wx containers)” and the program " program used 3.1.1 (wchar_t,Visual C++ 1900,wx containers,compatible with 3.0)" - versions identified in the message text look the same to me. What am I missing here?

Any assistance with this will be appreciated.

Running Windows 10 Pro, version 1809, 64 bit. Compiling with MS Visual Studio 2017, version 15.4.2 .

Doing a properties query on the original downloaded distribution executable shows Audacity version 2.3.0.0; compiled version from the cloned git distribution shows version 2.3.1.0. Doesn’t seem like this would be an issue, but maybe it is?

Thanks,
John Fishbeck

Hello:
After you successfully compiled Audactiy, were you able to launch it from the Release folder? If you could and you could not after re-location, it probably points to some missing files. You cannot just re-locate the executable and expect it to work.

Okay, sure - that makes sense. And now I see that the \Audacity\win\Release directory contains a full install build and configuration - I didn’t realize that the compilation process would do that.

So I have an existing Audacity 3.2.0.0 installation from the downloaded Windows installer, in which I have some settings and references to locations of saved projects which I’d like not to lose. How do I migrate my compiled Audacity with ASIO support to my currently installed Audacity installation. Do I just copy over all of the binaries from the \Audacity\win\Release directory into my existing C:\Program Files (x86)\Audacity installation folder?

I do see that my local user context settings are preserved in C:\Users\myusername\AppData\Roaming\audacity . So do I just replace the entire C:\Program Files (x86)\Audacity installation directory with the entire contents of the \Audacity\win\Release directory?

Do I need to accomplish something to ‘complete’ the installation of my compiled application?

Sorry to be a PITA on this. My developer days go a LONG way back to a much simpler world.

Regards,
John

Okay, I started out from scratch by deleting the entire contents of my wxWidgets and Audacity directories, and then used git to fetch fresh copies of the wxWidgets and Audacity repositories. I then successfully compiled (again, using MS VS 2017 version15.4.2 both wxWidgets (for release DLL) and Audacity (for release) (while the compilations succeeded without errors, there were numerous (hundreds) of warnings - is this normal?).

After the successful compilations I went to the \audacity\win\Release directory and launched Audacity.exe. The first time it launched correctly - and I saw ASIO offered as an audio host, confirming compilation with the ASIO support included. However, all subsequent attempts to launch the same executable from the same location immediately results in the error dialog box shown here:

AudacityErrDialogBox.jpg
Any clue as to what’s amok here? Or how I go about trying to determine the source of the problem?

Thanks,
John

I do not think you can migrate your compiled version 3.2.1 the way you want to migrate. Remember, you installed you 3.2.0.0 to your current location by using the installer. However, you do not have an installer for 3.2.1. Before going further, you need to find out whether you can launch the compiled version first. If you cannot, there are more things you have to do.

I’m sorry, I must not have written very clearly in my prior post.

I am now launching the freshly compiled version of Audacity.exe residing in the \audacity\win\Release directory . Execution immediately fails with the dialog box shown in prior post, text of which is “Unhandled unknown exception; terminating the application”. This is after doing a complete re-download from git of wxWidgets and Audacity, followed by a complete rebuild on wxWidgets and a subsequent complete rebuild of Audacity (both compiled using MS Visual Studio 2017). WXWIN and ASIOSDK_DIR environment variables are defined, present and correct. System was rebooted following the compilations.

I’m stuck in the water here. There is no information presented that I can find regarding the source of the problem, including perusing the application and system event logs.

How do I go about determining the source of this problem?

Okay, I have discovered the source of my problem, if not the underlying root cause of it. If I compile the 3.2.1.0 version of Audacity retrieved via git with the ASIOSDK_DIR environment variable defined (and correctly referencing the location of the downloaded ASIO SDK 2.3.2), the compiled Audacity.exe fails immediately when launched with the error dialog box shown above (“Unhandled unknown exception; terminating the application”).

However, if I compile the same Audacity source without the ASIOSDK_DIR environment variable defined the resulting executable runs fine without any issues.

Clearly there’s some issue with the inclusion of the ASIO SDK components in the build. The Audacity.exe compiled with ASIOSDK_DIR defined is 13,456,896 bytes, while the version compiled without ASIOSDK_DIR defined is 13,435,392 bytes. The ASIO version executable is 21,504 bytes larger than the non-ASIO version, so there’s obviously code added (presumably the ASIO support) to the ASIO version.

Help->About in the compiled 3.2.1.0 version shows version info as ‘Audacity 2.3.1-alpha-Feb 16 2019’ - might the fact that this is an alpha version of the next release be the source of the problem?

Is a current stable release version (3.2.0.0) of the Audacity source code available to try? I’m not seeing that as an option when I visit the Audacity git page.

Thanks,
John

If you cloned Audacity from the GitHub repository, you can checkout a previous release using the “tags” switch. For example:

git checkout tags/Audacity-2.3.0

If you just want to download the sourcecode as a ZIP archive, you can do that from the “Releases” section of GitHub. (Download link near the bottom of: https://github.com/audacity/audacity/releases/tag/Audacity-2.3.0)

Do you have a working ASIO setup? (A sound card with ASIO drivers, successfully tested in another ASIO app)

Hi again Steve,

First, thanks for working this with me.

I figured out the tags thing for git shortly before you posted your message re: git, versions and tags. Subsequently retrieved Audacity source for 3.2.0.0 and compiled same. Same results - 3.2.0.0 version compiled without ASIO launches and runs without issue; 3.2.0.0 version compiled with ASIO support fails immediately upon launching with the “Unhandled unknown exception; terminating the application” error dialog.

Do you have a working ASIO setup? (A sound card with ASIO drivers, successfully tested in another ASIO app)

I do not. I have a Behringer UMC202HD audio interface on order, and I was trying to prepare an ASIO-capable version of Audacity to use in anticipation of its arrival.

As an experiment I downloaded and installed Behringer’s driver, rebooted, then launched the Audacity version with ASIO support - same result; immediate failure upon launching. FWIW, I never see the user interface - the executable never makes it that far. Using the SysInternals ProcMon tool I can see Windows Explorer going through the steps to load Audacity and its associated components, but the Audacity executable never runs - so it appears that this is some sort of load time issue.

Do I understand from your question above that the ASIO version of Audacity will not launch (and in fact will fail catastrophically) unless an ASIO device is connected to the system at application launch time? I won’t always be using Audacity with the audio interface, so if true, this is a bit inconvenient.

Supplement to my posting.
Build.txt is a reference. But do not follow the links listed under 3 wxWidgets sub-item 2 for compiling Audacity just for ASIO for Windows 10. Sorry for the omission.

I would like to let you know that I am running Audacity 2.3.1 Alpha with ASIO compiled in a similar way to yourself and I have moved it to several of my Windows 10 machines, with and without ASIO devices, and had no problems. In the past I have posted a few issues such as an incompatibility with Realtek virtual ASIO drivers that cause the symptoms you seem to be having. I dig out the links and paste them here if I can. I am compiling and running the 32 bit version because of some issues with 64 bit ffmpeg compatibility but this may have been fixed now. Apart from the executable you just need the dll files but you may need to install VC runtime on any machines that don’t have it.

Here they are:-

https://forum.audacityteam.org/t/realtek-drivers-breaking-rme-asio-drivers-in-windows-10/49561/1

https://forum.audacityteam.org/t/compiles-and-runs-but-not-on-another-computer/48750/1

No, Audacity built with ASIO “should” work whether ASIO drivers are available or not, but (as I don’t use ASIO and rarely use Windows), I don’t know which “host” Audacity defaults to when built with ASIO support (probably MME, but I don’t know for sure). Also, because we don’t officially support ASIO, this feature is rarely tested by the QA guys, so we don’t have much information about how well behaved it is. I was just wanting to cover that base in case Audacity (with ASIO) was behaving badly.

I have seen problems like you describe if the machine has buggy ASIO drivers, so if ASIO drivers are installed, it is important that they work correctly.

Luckily, several of these questions have now been answered by roadsterUK (thanks roadsterUK):

Bingo.

I am nothing if not a stubborn and determined man. I built a debug version of Audacity 2.3.0.0 with the ASIO code included. I then proceeded to step through code until I found the source of the failure. Sure enough, when during initialization Audacity invoked function AddSources to add the audio driver named “Realtek ASIO” Audacity failed with the “Unhandled unknown exception; terminating the application” dialog box. The actual failure point is the invocation of function createBuffers invoked by function ASIOCreateBuffers inside of C++ file asio.cpp (line 221).

I updated the Realtek drivers to the latest available version; this made no difference - Audacity still failed when attempting to add the Realtek ASIO audio driver to its sources.

This was a show stopper as it stood. My Dell Latitude E6540 laptop system has integrated Realtek audio hardware, so the Realtek drivers are going to be there.

Having done a bit of coding in my day, I took matters into my own hands. I replaced the statement below, occuring at line 295 of DeviceManger.cpp:

         AddSources(i, info->defaultSampleRate, &mInputDeviceSourceMaps, 1);

with this:


     // If this ASIO driver name is not "Realtek ASIO" then go ahead and add it -
     // but don't do so for the buggy Realtek ASIO driver.
	 if (strcmp(info->name, "Realtek ASIO") != 0) {
	    AddSources(i, info->defaultSampleRate, &mInputDeviceSourceMaps, 1);
            }

I did a build of Audacity and, viola - the problem is gone, and Audacity 2.3.0.0 with ASIO support is running just fine on my system (it sees a test installation of ASIO4ALL). Having done all of this, I now have discovered (thanks to roadsterUK’s links) that deleting the Realtek entry from the ASIO branch in the HKLM\SOFTWARE\WOW6432Node registry branch also eliminates the problem. A more straightforward solution, for sure.

And yes, at least in a Windows environment, you can simply move the Audacity.exe and the required wxbase311* and wxmsw311* DLLs into an existing installation directory, and everything works swell. Probably don’t want to pull this trick with divergent versions, I suppose.

I do get it that since Audacity can’t officially include the Steinberg ASIO code that the developers won’t spend time on ASIO related issues. But this is a pretty serious shortcoming, and if anyone feels inclined to address it a fix could save grief for others.


My runtime environment in which the problem occurs without one of the fixes above:

Dell Latitude E6540 laptop with 16 GB memory
Windows 10 Pro 64bit OS, version 1809
Realtek sound driver, 6.00.0001.6098
Audacity 2.3.0.0, wxWidgets 3.1.1, ASIO SDK 2.3.2

To make it properly portable across other Windows machines, you should also include msvcp140.dll, vcruntime140.dll, EQDefaultCurves.xml, (and of course README.txt and LICENSE.txt), though ASIO builds cannot legally be given or sold to others due to the “non-distributable” clause in the Steinberg license.

How would you suggest that this is fixed? From your description it appears that the problem was due to the “Realtek ASIO” driver crashing PortAudio.

True enough. But knowing that at least one ASIO driver, the Realtek ASIO component, is buggy and causes failures, it would seem useful to me to catch runtime errors when loading an ASIO (or other) driver that results in a runtime error. As a proof of concept I replaced the following code in DeviceManager::Rescan

            AddSources(i, info->defaultSampleRate, &mInputDeviceSourceMaps, 1);

with this:

        try { AddSources(i, info->defaultSampleRate, &mInputDeviceSourceMaps, 1); }
        catch (exception& e)
          { cout << "Standard exception: " << e.what() << endl; }

And sure enough, when the code reached this point with the ‘Realtek ASIO’ driver the runtime error occurred, which was then logged into the MS VS debugger output window, with this text:

Exception thrown at 0x75F3B022 in Audacity.exe: Microsoft C++ exception: std::out_of_range at memory location 0x0305B918.

The program then continued on instead of terminating. So this bad driver behavior can be caught and handled. I would suggest that any attempt to load an ASIO (or any driver, for that matter) component resulting in a runtime error be trapped, and then 1) a dialog box be presented to the user informing him/her of the driver causing the problem and explaining that the guilty host and associated devices won’t be loaded and made available, and 2) clean out all host and device references associated with that driver.

Audacity does have an exception handling function (see AudacityException.cpp). But I am no Audacity developer, so I don’t know the architecture of the program sufficiently to understand where this needs to occur, and how to use the Audacity exception handling function. And since Audacity does support ASIO to the extent that one can compile a version using the Steinberg ASIO SDK, it would be a quite useful modification to the software to make it not fail in the face of a defective driver. Just one man’s opinion.

In any case, I do now have Audacity with ASIO support successfully working with a Behringer UMC202HD USB audio interface and the Behringer ASIO driver. Interestingly, there’s still (I believe) a lingering Realtek driver bug in there somewhere, even with the registry HKLM\SOFTWARE\ASIO\Realtek ASIO entry deleted. When in Audacity I switch from some other audio host to the ASIO host I get the error dialog shown here:

AudactiyErrDlg.PNG
But if I click the Ignore button the program continues on and I can select the Behringer ASIO input and output devices with everything working hunky-dory. I’m fairly certain this is because my unfamiliarity with the Audacity architecture means that I haven’t addressed the underlying issue everywhere in the code that it needs to be dealt with.

Regards,
John

Looks like a good approach. It could perhaps be useful to raise this issue on the Audacity developer’s mailing list (Redirecting to: https://audacity.gitbook.io/dev)