Posted in:

Several people have contacted me recently asking when NAudio will appear on The short answer is, hopefully soon. For the longer answer, read on…

The need for a decent build process

To release NAudio, there is a bunch of stuff I have to do, such as remembering to run all the unit tests and manual tests on all the operating systems and soundcards I can get my hands on (which in truth is a pretty limited selection). I then have to create a bunch of zip files for the binaries, the demo apps, and the source code to go on CodePlex. Then there is the release notes. A NuGet package adds yet another thing to a process that I would rather not be spending my free time on.

The hassle of doing all this means I don’t release as often as I should. However, I have created an MSBuild script for NAudio now that should make it a lot easier for me to create releases. And yes, one of the things it now does is creates a nupkg for NAudio.

The need to decide on a version numbering strategy

The approach to versioning I have taken with NAudio is that there is a major and minor version, and then the third digit gets updated regularly (used to be every checkin, but I have got lazy). If I am to release NAudio to nuget, I need to decide now how I will version it. Ideally I just want the public releases to be called “1.4”, “1.5” etc. But when I do bugfixes, what should their package number be? It doesn’t seem right if the package is 1.4.1 but the NAudio.dll version is There seems to be a mixture of choices taken by other libraries on, but I guess the safest is simply to use all four numbers as the package version and eliminate any possible confusion.

The need for an updated NAudio 1.4

After releasing NAudio 1.4 RC a while ago, I spotted a couple of bugs that I would really like to fix before calling it NAudio 1.4 final. Since I suspect that NAudio will get a lot more downloads once it is available on, I want to make people’s first experience as good as possible.

However, since I am well into writing the code for NAudio 1.5, I will need to create a branch to back-port the crucial fixes in. I’ve contacted CodePlex asking them to turn the NAudio repository into Mercurial so I can branch more easily. Hopefully once the conversion has taken place I can create my branch and start work towards an updated 1.4 release that can go on nuget. There will however be one outstanding issue remaining…

The need to decide on an approach to the x64 problem

The NAudio.dll is currently compiled with the platform target explicitly set to x86 . This means if your application is running as a 64 bit process it will fail when it tries to load NAudio. You need to mark your main project as x86 too for it to work.

There are two reasons for this. The main reason is that since my development environment is x86 (soon to change – I have ordered a new laptop and will finally enter the world of 64 bit), I cannot be sure that the interop all works properly in x64, even though I have heard reports that the vast majority of it is good to go on both architectures. However, until I am sure that all the interop (and there is a lot of interop in NAudio) is safe in Windows x64, it is easier for me to simply enforce running as a 32 bit process.

The second issue is that NAudio uses ACM codecs to perform its MP3 decoding, and I have heard rumours that when running in 64 bit windows, not all your ACM codecs appear. I will have a chance to test this for myself in the near future.

Going forwards, it may be easiest to unset the x86 only flag on the NAudio DLL and just strongly recommend to people that they set it on their calling executable. We could actually do this for people using nuget’s ability to use PowerShell to automate Visual Studio. But I would rather not fiddle with people’s project settings in this way.


I think NuGet is a brilliant development for the .NET open source community and I can’t wait to get NAudio on there. But it might be a few more weeks yet before I have sorted my own build and release processes out.

Want to get up to speed with the the fundamentals principles of digital audio and how to got about writing audio applications with NAudio? Be sure to check out my Pluralsight courses, Digital Audio Fundamentals, and Audio Programming with NAudio.


Comment by Ramon

Just use symentic versioning for your package:

In short, first digit means breaking api change, second means non breaking api change and third means bug fixes. This third revision is only useful if you also work with branches. If not then just put the code repository trunk version there

Comment by Mark H

@Ramon, that's a useful article, thanks. My minor releases do typically have a few breaking API changes though so I won't be following it exactly.

Comment by sporn

Hi Mark, I use your excellent library on my open source project ispy -

any chance of adding a link to my website from your project page?

Thanks and great work!

I went to Southampton Uni at the same time as you by the way - studied Aero/Astro Eng.


Comment by Mark H

hi Sean, the link is already up on the NAudio home page.

Comment by Sciclops

Have you had success with the x86 to x64 conversion?
Thanks and good work!

Comment by Sciclops

Have you been successful with the conversion from x86 to x64?
Great work BTW!

Comment by Mark H

yes, latest NAudio should work just fine in x64. However, there are reasons why you might want to run as a 32 bit process, such as if you want to make use of 32 bit ACM codecs.

Comment by Sciclops

You are correct! I got the NAudioDemo demo, ran it in 64 bit mode. All I did was change the FW to 4.5 and the platform target:anyCPU, and it ran flawlessly.

I tried running the WPF Demo, but there is no recorder on it. Cool drum sample though.

You have another WPF sample on

I will try to get this one working on 64 bit.

Thanks for your help! :)

Comment by Sciclops

I am getting all sorts of issues when trying to run the .net voicerecorder WPF 64 bit.
Do you have a working demo of the voice recorder running on 64 bit?

BTW when is Microsoft going to purchase your NAudio work? This is terrific what you have here!!!


Comment by Mark H

for a 64 bit voice recorder, you'd need to upgrade it to use a newer version of NAudio.

Comment by Sciclops

I replaced the NAudio.dll, like you suggested and I got a number of errors.
I am a bit lost, I can't figure out how to resolve these errors. Nothing I do works.
I picked up the sample code from the codeplex -.NET AudioRecorder project.
I got the latest NAudio.dll and replaced in the dependencies folder:
current running version
previous version

Thanks :)

Comment by Mark H

well you'll have to fix the errors one by one. Without seeing the error messages I can't help you.

Comment by Sciclops

RE: .NET AudioRecorder CodePlex – 64 bit Here are the errors I get:
***Error 4 Metadata file 'C:\NAudio\NAudio WPF voicerecorder_f652f98eb1ff\VoiceRecorder.Audio\bin\Debug\VoiceRecorder.Audio.dll' could not be found C:\NAudio\NAudio WPF voicerecorder_f652f98eb1ff\VoiceRecorder.Core\CSC VoiceRecorder.Core


**Error 5 The tag 'PolygonWaveFormControl' does not exist in XML namespace 'clr-namespace:VoiceRecorder.Core;assembly=VoiceRecorder.Core'. Line 45 Position 10. C:\NAudio\NAudio WPF voicerecorder_f652f98eb1ff\VoiceRecorder\RecorderView.xaml

Error 6 The tag 'WaveFileTrimmerControl' does not exist in XML namespace 'clr-namespace:VoiceRecorder.Core;assembly=VoiceRecorder.Core'. Line 9 Position 10. C:\NAuduio\NAudio WPF voicerecorder_f652f98eb1ff\VoiceRecorder\SaveView.xaml

Comment by Mark H

those are strange errors, and not really related to the NAudio dll changing. Could you build successfully before swapping out NAudio?

Comment by Sciclops

Will do. I'll let you know what the outcome is. Thank you! :)

Comment by Hagen

Hi Mark,
are you planning to strongly sign the assembly you publish via NuGet? Because that would make it usable from any assembly, and not from unsigned ones only.

Comment by Mark Heath

that's a highly contentious issue and the guidance has changed over the years as signing can introduce as many problems as it solves. If there is an NAudio 2.0 then I might sign it. For current use I generally recommend people just strong sign it themselves.

Mark Heath