NAudio 3: a .NET audio and MIDI library split into focused packages

What NAudio solves, and who it is written for

NAudio is a C# library for audio and MIDI work inside .NET applications. The README describes it as an open source .NET audio library written by Mark Heath, and the feature list covers playback, capture, format conversion, mixing, effects, MIDI, and VST 3 hosting. That range is the point. A developer who needs to play a WAV file, record from a microphone, convert a stereo stream to mono, or read a Standard MIDI File would otherwise be writing P/Invoke wrappers against WASAPI, WinMM, or ALSA by hand.

The audience is .NET developers building desktop or server-side audio tooling. The repository ships several demo applications, and the README points to them as the quickest way to see how the features fit together: NAudioDemo (WinForms), NAudioWpfDemo, and the smaller NAudioConsoleTest, AudioFileInspector, MidiFileConverter, and MixDiff tools. The README makes a useful admission here: the demos are kept up to date, while some tutorials on the internet refer to old versions of NAudio. If you are learning the library from search results, that warning matters more than it looks.

The licence is MIT, and the README links to the LICENSE file at the repository root. That is permissive and imposes few conditions on redistribution, but the repository also contains NAudioStrongNameKey.snk, so if you fork and rebuild under your own strong name you need to deal with the signing setup rather than assume the published package's identity transfers.

How NAudio 3 splits the assembly and what runs where

The headline change in NAudio 3 is that the single NAudio assembly is split into focused packages. The README states the NAudio meta-package still pulls the Windows stack together, so existing consumers see no change, and that on a non-Windows target framework it resolves to the cross-platform pieces only. That last clause is the mechanism worth understanding: the same package reference produces a different dependency graph depending on the target framework.

The cross-platform set is NAudio.Core, NAudio.Midi, NAudio.Effects, NAudio.Sampler, and NAudio.SoundFile, which the README says run on Windows, Linux, and macOS. NAudio.Core carries the WaveStream and ISampleProvider model, WAV and AIFF I/O, mixing, resampling, DSP, and sequencing. NAudio.SoundFile is the one that surprised me most on reading the table: it reads and writes WAV, AIFF, FLAC, Ogg-Vorbis, Opus, and MP3 through libsndfile, which means encoding those formats no longer depends on codecs installed on the machine.

The Windows-only packages are NAudio.Wasapi, NAudio.WinMM, NAudio.Asio, NAudio.Dmo, NAudio.WinForms, and NAudio.Vst3. Linux gets NAudio.Alsa for playback and capture via libasound. The README lists NAudio.Vst3 as preview, and it is Windows-only, so the VST 3 hosting feature is not available to Linux or macOS consumers.

Native-AOT compatibility is called out for NAudio.Core, NAudio.Midi, NAudio.Wasapi, NAudio.Dmo, NAudio.Sampler, NAudio.SoundFile, and NAudio.Alsa. Note the gaps: NAudio.WinMM, NAudio.WinForms, and NAudio.Vst3 are absent from that list, and the README does not explain why. If you are trimming or compiling ahead of time, that omission is something to check against your own dependency set rather than assume.

Installing NAudio from NuGet and playing a file in C#

The README describes the NAudio meta-package as the right default: it gets you the full Windows stack, and on a non-Windows target framework it resolves to the cross-platform pieces only. The README does not print a CLI command of its own, so the package name is what you work from when adding it to a project.

If you want a smaller surface, reference the individual packages instead. The README names NAudio.Core, NAudio.Midi, NAudio.Wasapi, NAudio.WinMM, NAudio.Asio, NAudio.Dmo, NAudio.WinForms, NAudio.Sampler, NAudio.SoundFile, NAudio.Alsa, NAudio.Vst3, and NAudio.Extras. For a Linux service that only reads and writes sound files, NAudio.SoundFile plus NAudio.Core is a narrower choice than the meta-package.

The README states the minimum target framework for NAudio 3 is net9.0. That is the constraint to set in your project before you try to compile, because a lower target will not resolve the version 3 packages.

For a first real use, the README points to the documentation site for tutorials and the full API reference, and to the demo applications in the samples directory. The NAudioConsoleTest sample is the smallest of those, and it is the one to open first if you want to see the WaveStream and ISampleProvider model in code rather than in prose. The README does not inline a playback snippet of its own, so the demos and the documentation site are where the working examples live.

One practical note from the repository layout: the solution file is NAudio.slnx, and the build is driven by Directory.Build.props and Directory.Build.targets. If you clone the repository to read the source rather than consume the packages, that is the build entry point, not a classic .sln.

Where NAudio 3 stops: framework floor, Windows-only features, and preview code

The hard boundary is the target framework. NAudio 3 drops legacy .NET Framework and .NET Standard 2.0 support, and the minimum is net9.0. If your product ships on .NET Framework, NAudio 2 is the version you stay on, and the README points to Migrating from NAudio 2 to NAudio 3 for the changes involved. The repository also carries a v2.4.0 release from 2026-08-26, which is the line to follow if you cannot move the framework floor.

The second boundary is platform. ASIO, WASAPI, WinMM, DMO, WinForms controls, and VST 3 hosting are all listed as Windows packages. On Linux you get ALSA capture and playback, and on macOS the README does not name a dedicated output package at all; the cross-platform packages cover file I/O, MIDI, effects, the sampler, and the core stream model. If your goal is low-latency multichannel capture on macOS, the package table does not show a route for it.

Third, NAudio.Vst3 is marked preview. Treat it as a moving target rather than a settled API surface, and check the release notes before depending on a specific hosting behaviour.

The upgrade path itself is a cost. The README directs readers to Docs/MigratingFromNAudio2.md for every breaking change with before and after code, and to RELEASE_NOTES.md for the full list. The README does not document rollback, so if a migration goes wrong mid-project the guidance for going back is not published. Plan the upgrade as a branch you can abandon, not a change you apply in place.

NAudio against a thin wrapper over the platform APIs

The obvious alternative is not another .NET audio library but writing the platform interop yourself. A developer who only needs to push PCM to the default output device on Windows can call WASAPI through P/Invoke and avoid a dependency entirely. The difference in approach is what you inherit. A hand-written wrapper gives you exactly the calls you need and nothing else, and it gives you full control over the COM lifetime and threading model. NAudio gives you a stream abstraction, a 32-bit floating point mixing engine, resampling with a choice of algorithms, and format conversion across a long list of codecs, but you take the package graph and the framework floor with it.

The trade-off shows up at the edges. If your requirement is one output device and one format, the library is more surface than you need, and the net9.0 minimum is a constraint your own wrapper would not impose. If your requirement is reading MP3, FLAC, Ogg Vorbis, and Opus on Linux and Windows with the same code, or hosting a VST 3 instrument, the amount of interop you would write by hand is the reason the library exists. NAudio.SoundFile in particular replaces a per-platform codec hunt with a single libsndfile-backed package.

There is also a maintenance argument on the other side. The last push to the repository was on 2026-09-21, and v3.1.0 was released on 2026-09-07, so the project is being worked on. A hand-written wrapper is a file you own forever, with no upstream to fix a driver quirk for you.

Licence, maintenance, and the cost of tracking NAudio 3

NAudio is MIT licensed, and the LICENSE file sits at the repository root. MIT is permissive: it allows use in closed-source products and modification, provided the licence text and copyright notice travel with the distribution. The NAudioStrongNameKey.snk file in the repository means the published assemblies are strong-named, so if you build your own fork you will need to handle signing yourself. That is a build detail, not a licence term, and it is worth confirming with your own legal and release process rather than taking my reading of it.

The upgrade cost is real but bounded. The README frames NAudio 3 as a major release with a documented migration guide, and the release cadence shows v3.0.1 on 2026-08-18, v3.1.0 on 2026-09-07, and v2.4.0 on 2026-08-26. Two lines are being maintained in parallel, which is good news if you are stuck on NAudio 2 but also means you have to decide which line you are on. The last push was on 2026-09-21, so the repository is not dormant.

What is not published is a deprecation policy. The README does not say how long the NAudio 2 line will receive fixes, and it does not document rollback if a 3.x upgrade breaks something. If your team needs a supported window before committing, that is a question to raise upstream rather than infer from the release history.

Editorial conclusion

Adopt NAudio if you are building a net9.0 or later application that needs playback, capture, MIDI, or format conversion and you are willing to take the Windows-specific packages alongside the cross-platform core. Stay away if you are pinned to .NET Framework or .NET Standard 2.0, since the minimum target is now net9.0, or if you need a Linux path for VST 3 hosting or ASIO, both of which the package table lists as Windows-only. Before you commit, read Docs/MigratingFromNAudio2.md for the breaking changes in the APIs you actually call, and confirm which packages your target framework resolves to when you install the NAudio meta-package.

Frequently asked questions

Official sources

1. License: MIT
2. naudio/NAudio on GitHub
3. Project website
4. README
5. Releases