FAudio: an accuracy-focused XAudio reimplementation for FNA

A compatibility target, not an audio design

The README is blunt about the intent. FAudio is an XAudio reimplementation that focuses solely on developing fully accurate DirectX Audio runtime libraries for the FNA project, including XAudio2, X3DAudio, XAPO and XACT3.

That word solely sets the scope. This is not a general purpose audio library and it does not try to be one. It exists so that a game written against Microsoft's XAudio stack can run on a platform where those libraries do not exist, with behaviour that matches closely enough that the game does not notice. Every design question in the project is answered by fidelity to the original API rather than by what would be elegant in a fresh design.

The scope is also wide for something described as a reimplementation. XAudio2 is the core mixing and streaming API, X3DAudio is the spatial audio helper set, XAPO is the extension processing framework, and XACT3 is the higher level audio engine. Supporting all four means carrying over the interactions between them, not just each in isolation.

The project website is at fna-xna.github.io, and the repository topics list the expected platforms, including linux, macos, steamos and windows, alongside the API names x3daudio, xact and xapo.

SDL is the only dependency

The Dependencies section states that FAudio depends solely on SDL 3.2.0 or newer, and adds that FAudio never explicitly uses the C runtime.

A single dependency is a deliberate position for a library that sits under a game. The usual objections to a small dependency count are about transitive weight and about version conflicts, and for a library whose host is a game runtime those objections carry less weight, because the runtime already links SDL in most setups. The stated SDL floor of 3.2.0 is a recent release, so it is worth checking that the SDL version on the target system is new enough before assuming a build will work.

The second sentence is a stronger constraint than it first appears. Not explicitly using the C runtime is a statement about how the library is written, and it has consequences for how it is ported and how it behaves at the edges, since there is no C library to lean on for string handling or allocation. It is the sort of discipline that makes a portability-focused library portable.

The C# side is separate. The README says FAudio was written to be used for FNA's Audio/Media namespaces, and that the library is accessed via FAudio#, which is in the csharp/ directory. So the architecture is a native C++ core with a managed binding, and the C# layer is what an FNA-based game actually talks to.

Building on *nix is a cmake invocation

The build instructions for *nix platforms are short and use cmake. The sequence is:

    $ mkdir build/
    $ cd build/
    $ cmake ../
    $ make

The out-of-source build directory is the standard pattern, and the top-level CMakeLists.txt at the repository root drives the configuration.

Windows, Xbox GDK, and the Apple platforms each have their own directory rather than sharing the cmake path. For Windows the README points at the `visualc/` directory, for the Xbox GDK at `visualc-gdk/`, and for iOS and tvOS plus macOS universal binaries at the `Xcode/` directory. That spread of build systems is the cost of supporting that many targets, and it is also a hint about where a contributor should look first: the cmake path is the one that is cross-platform, so a change that has to work everywhere has to survive cmake as well as the platform specific ones.

The repository layout supports the same reading. There are `include/` and `src/` directories for the library itself, `extensions/` for the XAPO-related work, `csharp/` for the managed binding, `utils/` for helper tools, `cmake/` for the cmake modules, and `tests/` for the test suite.

The unit tests exist to prove behavioural equivalence

FAudio includes a set of unit tests which document the behavior of XAudio2 and are to be run against FAudio to verify it has the same behavior. That is the stated purpose, and it is a stricter goal than passing a test suite.

The tests are not built by default. You set `BUILD_TESTS=1` to build them, and then run the output:

    $ ./faudio_tests

The comparison runs in both directions. The README describes the tests as documenting XAudio2 behaviour so that FAudio can be verified against it, and separately explains how to build a Windows executable to run the same tests against the real XAudio2, using the provided Makefile in the tests directory, which requires mingw-w64 to build:

    $ cd tests/
    $ make faudio_tests.exe
    # run faudio_tests.exe on a Windows box

That last step is the interesting one, because it means the test suite is portable enough to be executed against the Microsoft implementation on Windows and against the reimplementation elsewhere, and the results compared. This is the mechanism by which a project that claims accuracy can demonstrate it rather than assert it, and it is the part of the repository that a reviewer should read first.

Monthly releases, and two different licence descriptions

The release pattern is regular. The recent releases are 26.10 on 2026-10-01, 26.09 on 2026-09-01 and 26.08 on 2026-08-01, and the naming convention itself is a monthly version scheme rather than semver. The repository is not archived and the last push was on 2026-10-01, the same day as the newest release, so the branch and the release line are moving together.

The licence is where the documentation is less clear. The README states that FAudio is released under the zlib license and points to the LICENSE file for details, and the LICENSE file is at the repository root. The repository listing, however, classifies the licence as Other, a custom licence that GitHub cannot classify.

Those two statements are not necessarily in conflict, since a permissive licence that GitHub does not have a classifier for would be recorded exactly that way, and the zlib licence is short and well known. But the practical advice is the same in either case: read the LICENSE file rather than relying on the badge or the metadata, and if you are shipping FAudio in a product, check what attribution the text requires.

The repository also carries AGENTS.md and CLAUDE.md at the root, which are the files an AI coding assistant is pointed at, and that in itself tells you something about how the project is maintained today.

Editorial conclusion

FAudio fits a maintainer of FNA, or anyone porting a title that expects the XAudio family of APIs, and it is a reasonable reference for how the DirectX Audio behaviour is specified. It is the wrong choice for a new audio stack, since its design goal is compatibility with an existing Microsoft API rather than a clean design. Verify first that your project actually calls into XAudio2, X3DAudio, XAPO or XACT3, that SDL 3.2 or newer is acceptable as your only dependency, and that you read the LICENSE file directly, since the repository listing and the documentation describe the licence differently.

Frequently asked questions

Official sources

1. FNA-XNA/FAudio on GitHub
2. Issues
3. Project website
4. README
5. Releases