ASIO support in Audacity 2.4.2

This post is only relevant to people that are building Audacity from source on Windows 10 for the purpose of adding support for ASIO.

At time of release, ASIO support was not available in the Audacity 2.4.2 code, but will be available again in Audacity 3.0.0.


At time of posting, Audacity 3.0.0 is in early alpha development and is not yet ready for production work, so one of the Audacity developers has kindly provided a patch for Audacity 2.4.2. This attached patch adds the ability to build Audacity 2.4.2 (on Windows 10) with ASIO support.
asio.patch (2.39 KB)

I was going to try to just cherry pick 1ec7fd56c166f2d2a7c343d8f023fc2485d463dd on top of 2.4.2 Looks like this patch does exactly that. Will post again if it builds successfully

Audacity.exe compiles fine, and the two failing projects still fail, however there is still no ASIO support on the compiled exe

Good news! Please go back to the old ASIO build methodology via “audacity.sln”; that worked well. Meantime, 2.4.1 does what I need. Thanks.

I’ve submitted a PR, which the sole commit fixes the previous patch, so that ASIO does actually compile. Here is an updated patch.
asio.patch (2.4 KB)
If you already applied the first patch then the following patch can be applied on top of that patch.
patch for patch.patch (1006 Bytes)
I was able to compile it in x32 Release with VSCE 2017.

How/where is this patch called into the build process? Is it referenced in CMake? Thanks.

Yes, if you install the patch, all you need to do is run CMAKE again, then build the solution that CMAKE generates - If you’ve already compiled WX.

Hello everyone,

I have only very little programming skills, but I have always managed to compile the current Audacity version with ASIO support.

Unfortunately, in the current version 2.4.2 it does not work for me anymore. I get 38 errors when compiling and I think this is due to the missing ASIO patch that was provided here.

Maybe someone can tell me how exactly I can insert this patch into the source code.

I would be grateful for any help.

Best regards
Christian

sure, use this tool: Git - git-apply Documentation
it comes with git, so assuming that you managed to clone audacity/wxwidgets with the correct 3.1.3-audacity-fixes branch, then all you need to do is open a terminal in the audacity repo and run

git apply asio.patch

sent from my phone

Hello micsthepick,

thanks so lot. That worked…sort of.

Audacity works, also the ASIO implementation but I still get these 38 errors during the compile process. Strangely enough, those errors do not occur when compiling Audacity 3.0.0 alpha. I will now see if everything I need is working and if necessary open a separate threat for it.

Thanks again!

Best Regards
Christian

@doubleO7 no worries, I’m thinking that a couple of projects later in the dependency chain were left intentionally broken in the windows build, as two were failing when I built it too

Not sure what I was doing wrong earlier, but with this instruction I got ASIO to build on 2.4.2. Thanks.

OK, I (finally!) got Audacity 2.4.2 with ASIO to compile on Windows 10. :smiley:

I would like to share with you my steps, so that you may/might be able to duplicate them. My thanks to steve, Apesbrain and micsthepick whose posts gave me the solution I only had to duplicate and document; and to Steve A Lee for the 2.4.1 version of this cmd file.

  1. I have previously download Visual Studio Community Edition 2017. See https://visualstudio.microsoft.com/vs/older-downloads/
    Added 2/6/21: be sure to include the Desktop Development in C++ Workload Package.
  2. I have previously downloaded and intstalled git; if you haven’t done this do this now. See https://git-scm.com/download/win
  3. Download and install win32 installer for cmake-3.19.1 from https://cmake.org/download/
  4. Download current python 3.9 from https://www.python.org/downloads/windows/
  5. Create c:\proj242 directory
  6. Download latest ASIO SDK from https://www.steinberg.net/en/company/developers.html
    then unzip the ASIO SDK folder and move the folder to c:\proj242.
  7. Rename this folder to “ASIOSDK”
  8. copy the following code build-audacity.txt to c:\proj242\build-audacity.cmd [Note .cmd extension!]
    This will download the source code for audacity widgets, audacity 2.4.2, then compile, cmake, and build everything.
    build-audacity.txt (2.68 KB)
  9. copy the next segment of code and save it to c:\proj242\asio2.patch
    asio2.patch (2.4 KB)
  10. There should be two files and one folder in c:\proj242:
    build-audacity.cmd
    asio2.patch
    ASIOSDK
  11. Press Windows-R and type “cmd”
  12. type “cd c:\proj242”, then type “build-audacity”
  13. The compiled progam will be built to C:\proj242\audacity\win\bin\Release\Audacity.exe

Thank you for putting in this effort and documenting it so thoroughly. To me the fact that you have needed to do this illustrates where the entire process has gone wrong so I’ll be sticking with 2.4.1 and falling back on Studio One as my recording software if necessary.

I’m not sure what that means, but the reason why this is necessary is because:
Building with ASIO support requires using the ASIO SDK source code, but the ASIO SDK license prohibits distribution of the source code. Audacity’s open source license requires that the full source code is freely available, so it is impossible to distribute an ASIO version of Audacity without violating one or other license.

would it be possible to have an automated build (such as GH actions) with no artifacts that verifies that the ASIO build succeeds?

would it be possible to have an automated build (such as GH actions) with no artifacts that verifies that the ASIO build succeeds?
Top

That’s a very good suggestion plus a runtime smoke test too. It’s a real shame to break existing functionality on a release, especially a patch release.

However most cloud-located CI/CD systems like GitHub actions are Linux based :frowning:
I can only think of Azure DevOps offering Windows VM/Containers. I’ve used it when it was relatively new ) and it was impress if aimed at large corps. II believe now integrates with GitHub. There’s a free tier and perhaps OSS pricing. I could explore it’s used if there is sufficient interest.

Anyway you’re welcome to use my script if it helps. It’s MIT licensed and could easily be adapted to build using any specified release.

As far as I’m aware, the ASIO SDK cannot be included in the source code (that would probably constitute “distribution” and so violate Steinberg’s license), so it would need to be downloaded from Steinberg at build time. I don’t know if Steinberg allow downloading to bypass their license acceptance page, or any form of automated downloading of their SDK. Even if they do allow that now, they have every right to block such downloads at any time without notice.


The current /win/build.txt seems to say that MSVC is only used for building WxWidgets. On Linux, WxWidgets may be built with cmake. Can WxWidgets be built with cmake on Windows? If so, it may be possible to make it easier to use the script by removing the requirement for “Visual Studio Community 2017”. Perhaps worth looking at?

This is awesome and very step-by-step. Thank you.

I followed it step-by-step, however, I’m having a problem somewhere:

‘nmake’ is not recognized as an internal or external command,
operable program or batch file.
– Building for: NMake Makefiles
– The C compiler identification is unknown
– The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:81 (project):
The CMAKE_C_COMPILER:

cl

is not a full path and was not found in the PATH.

To use the NMake generator with Visual C++, cmake must be run from a shell
that can use the compiler cl from the command line. This environment is
unable to invoke the cl compiler. To fix this problem, run cmake from the
Visual Studio Command Prompt (vcvarsall.bat).

Tell CMake where to find the compiler by setting either the environment
variable “CC” or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.


CMake Error at CMakeLists.txt:81 (project):
The CMAKE_CXX_COMPILER:

cl

is not a full path and was not found in the PATH.

To use the NMake generator with Visual C++, cmake must be run from a shell
that can use the compiler cl from the command line. This environment is
unable to invoke the cl compiler. To fix this problem, run cmake from the
Visual Studio Command Prompt (vcvarsall.bat).

Tell CMake where to find the compiler by setting either the environment
variable “CXX” or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.

Thanks for reporting this difficulty. I will try to look into this tomorrow. :confused: