# CSCore: a .NET audio library with a Windows centre of gravity

> A mature managed audio library for .NET whose codec and DSP layers are portable, and whose device layer is not.

**filoe/cscore** — An advanced audio library, written in C#. Provides tons of features. From playing/recording audio to decoding/encoding audio streams/files to processing audio data in realtime (e.g. applying custom effects during playback, create visualizations,...). The possibilities are nearly unlimited. 

- Repository: https://github.com/filoe/cscore
- Stars: 2,366 · Forks: 465
- Language: C#
- License: NOASSERTION
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/filoe-cscore

## A C# audio library with a Windows centre of gravity

CSCore describes itself as a free .NET audio library written entirely in C#, and the feature list matches that claim: playing and capturing audio, encoding and decoding codecs, and running DSP on the stream while it plays. The pitch is that a music player, a voice chat client or an audio recorder can be assembled out of the pieces instead of binding directly to a platform audio API.

The important qualifier sits in the same paragraph as the platform list. Windows is the supported target, and Linux and macOS are described as experimental, with a pointer to the netstandard branch in the repository. That branch matters if you deploy to .NET Core, because code compiled there will not have WASAPI, DirectSound or XAudio2 underneath it. What survives the crossing is the codec and processing layer, which is managed code with no Windows dependency.

Licensing is split rather than uniform. The core library is under the MS-PL, while CSCore.Ffmpeg is LGPL. Repository metadata reports no detected license, so a commercial product needs to treat those two terms separately.

## Installing the core package and the FFmpeg wrapper

NuGet is the primary route in the README, with a git clone as the alternative:

```bash
Install-Package CSCore
```

Codec support that does not come from the operating system lives in a separate package, and it is installed as a prerelease:

```bash
Install-Package CSCore.Ffmpeg -Pre
```

That prerelease flag is not incidental. The FFmpeg wrapper has sat on a prerelease channel for years, which tells you how to expect to pin versions for anything built on it.

The clone route works too, and the repository tree gives you the layout to expect: a `CSCore/` directory for the main library, `CSCore.Ffmpeg/` for the interop layer, `CSCore.Test/` for the test project, and a `Samples/` directory holding about twenty runnable examples. A `global.json` pins the SDK version for the solution, so a current SDK will not build this without checking that file first.

## The codec list and which of them are free

Coverage is broader than a typical managed binding: MP3, WAVE across PCM, IEEE float, GSM and ADPCM variants, FLAC, AAC, AC3, WMA, raw data, and OGG Vorbis through NVorbis. FLAC and AAC are the two most managed stacks skip, and having FLAC without a native dependency is the sort of detail that decides whether a project handles archival work or only playback.

Two entries in that list deserve a closer read. Media Foundation encoding and decoding is Windows-only, and DirectX Media Objects is a wrapper around a DirectX component. Both are COM-era technology and neither exists outside Windows. The README adds that some codecs are only available on certain platforms and defers to the project's Codeplex page for the per-platform detail, which is the least helpful documentation in the repository.

FFmpeg is the escape hatch. Because the core treats decoding as an interface, `CSCore.Ffmpeg` slots in for the long tail of formats without the core changing. The `Samples/FfmpegSample/` directory has a worked integration rather than only documentation.

## Realtime processing as an ordered chain of nodes

The architecture claim is extensibility, and it shows up most clearly in the realtime section. Audio data passes through processors in whatever order you want, and a custom processor implements the same interface the built-in ones do. Effects, analyzers and decoders are all processors, which is why the sample set includes a visualization and an FFT rather than only filters.

The DSP list is practical: FFT, a resampler, channel mixing driven by a custom channel matrix, a generic equalizer, and an effects set covering echo, compressor, reverb, chorus, gargle and flanger. Release 1.1.0 added biquad filters, lowpass, highpass, bandpass, notch and both shelving variants, and 1.2.0 added pitch shifting, which usually arrives via a native library and here is managed code.

The samples isolate the parts that are easy to get wrong. `Samples/BiQuadFilterSample/`, `Samples/Equalizer/`, `Samples/FadingSample/`, `Samples/SimpleMixerSample/` and `Samples/SoundTouchPitchAndTempo/` each cover one link in the chain. `Samples/EndpointAudioMeterSample/` is the one to read for input levels, since it sits on the Core Audio API wrapper rather than on the processing code.

## Four output paths and what each one costs

Speaker output is not one thing in CSCore, it is four, and the choice is a latency and control tradeoff rather than a preference.

WaveOut is the oldest and least capable. DirectSoundOut is described as realtime streaming. WASAPI is the modern path, with loop and event callback modes plus exclusive mode, which lets a device bypass the shared engine for the lowest latency at the cost of exclusive access to the endpoint. XAudio2 targets games, with XAudio2.7 and XAudio2.8 support and 3D audio through `Samples/X3DAudioSample/`.

Recording mirrors that split: WaveIn, WASAPI in the same loop and event callback variants, and WASAPI loopback capture for recording what the soundcard plays rather than what a microphone hears. That last one captures a system audio mix on Windows without a virtual device, and it is the feature many people end up shopping for.

The Core Audio API wrapper covers WASAPI, Windows Multimedia Devices, the audio session API and endpoint volume, which is where the meter sample gets its numbers. It also means a good share of the library is P/Invoke, so the netstandard path and the Windows path are quite different code underneath one package name.

## Pushed in 2026 by a release line that stopped in 2017

The metadata deserves a slow read. The last push was on 2026-09-17, so the repository is not dormant. The last tagged release, 1.2.1.2, was published on 2017-10-22, preceded by 1.2.0 on 2017-02-05 and 1.1.0 on 2016-05-28. Nine years of commits against a release line that ended in 2017 is the central fact about depending on this.

Practically, a NuGet user installs code from 2017 while anyone building master picks up almost a decade of unreleased changes with no changelog to match. There are 103 open issues against 2363 stars and 465 forks, a low ratio, though the README points at Gitter and Stack Overflow for support rather than suggesting the tracker is unattended.

The project is also visibly from an earlier era in ways that affect evaluation: a PayPal donation button, a Gitter chat badge, Codeplex as the documentation home, and sharpDox-generated API docs hosted from the repository. Those are not criticisms, only signals that the surrounding infrastructure moved on and the package did not. The README does list real users, including the Dopamine music player and the Hurricane player, which is reasonable evidence the core code is sound even where the tooling is dated.

## Conclusion

CSCore is still the most complete managed audio stack for Windows, and its codec and DSP layers are good enough to reuse on other platforms once you accept losing the device layer. What the repository does not give you is a release line: the newest tagged build is 1.2.1.2 from October 2017, while the last push was 2026-09-17, so a NuGet install and a master build are very different things. Start with the Samples directory, particularly AudioPlayerSample and Recorder, since those show the shape of the processor chain faster than the documentation does, and pin a version deliberately if you depend on CSCore.Ffmpeg rather than taking the prerelease channel.

## FAQ

### Does CSCore work on Linux and macOS?

Partly. The README calls Linux and macOS experimental and points to a netstandard branch for that build. Codecs and DSP are managed code and carry over, but the device layer does not: WASAPI, DirectSound, XAudio2 and the Core Audio API wrapper are all Windows-only, so playback and capture need a different backend there.

### What is the difference between CSCore and CSCore.Ffmpeg?

CSCore is the core library, covering playback, recording, a set of built-in codecs and DSP. CSCore.Ffmpeg is a separate package under the LGPL that adds FFmpeg decoding for the long tail of formats, and it is installed as a prerelease with Install-Package CSCore.Ffmpeg -Pre.

### Is CSCore still maintained?

The repository was last pushed on 2026-09-17, so commits continue. The newest tagged release is 1.2.1.2 from 2017-10-22, which means the published package and the master branch are close to nine years apart and serve different purposes.

### How do I capture system audio on Windows with CSCore?

Use WASAPI loopback capture, listed under recording alongside WaveIn and the other WASAPI modes. It records what the soundcard is playing rather than what a microphone hears, which removes the need for a virtual audio device when you want to capture an application's output.

## Sources

- [filoe/cscore on GitHub](https://github.com/filoe/cscore)
- [Issues](https://github.com/filoe/cscore/issues)
- [README](https://github.com/filoe/cscore/blob/master/README.md)
- [Releases](https://github.com/filoe/cscore/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/filoe-cscore