FxSound for Windows: install, build, and what the AGPL source actually gives you

What FxSound does that a plain Windows equalizer does not

The README describes FxSound as a digital audio program for Windows PCs whose background processing acts as "a sort of digital soundcard for your system." That phrasing matters. The application is not a player and not a plugin host. It inserts itself into the system signal path so that other applications' output passes through it, and the README states that signals get "clean passthrough when FxSound is active." On top of that passthrough sit the effects: volume, timbre, and equalization, which the README groups as active effects for shaping and boosting sound.

The audience is Windows users who want per-system processing rather than per-application processing. If you only need an equalizer inside one media player, this is more machinery than the job requires, and it asks you to install a kernel-level audio driver to get it. That trade-off is the whole product: system-wide coverage in exchange for a driver and a background process.

The repository itself is the DSP and application source, not the driver. The README is explicit that the driver ships with the official installer, and that installing FxSound is a prerequisite for running a source build. So the open source portion is the part you can read, modify, and rebuild, while one runtime dependency stays outside the repository.

Three components: GUI, audiopassthru, and DfxDsp

The README splits FxSound into three components, and the top-level repository layout matches that split. The fxsound/ directory holds the GUI application, which uses the JUCE framework. audiopassthru/ is a module the application uses to interact with audio devices. dsp/ contains DfxDsp, the module that actually processes audio. Alongside those sit fxdiag/, fxmcp/, Installer/, Resources, bin/, docs/, and release/.

That separation is the useful part of the architecture for anyone reading the code. Device enumeration and stream handling live in one project; sample processing lives in another; the JUCE application wires them together and draws the interface. If you want to understand the equalization and dynamics behaviour, dsp/DfxDsp.vcxproj is where to start. If you want to understand how FxSound attaches to a device, audiopassthru/audiopassthru.vcxproj is the entry point.

The build instructions confirm the dependency direction: from the FxSound_App project you add references to audiopassthru and DfxDsp. The README also notes that Projucer cannot add those dependency projects when it exports FxSound.sln, which is why the manual steps exist. That is a real friction point, not a documentation gap you can route around with a flag.

Installing FxSound and a first run on Windows

The README points at the vendor installer rather than a package manager. There is no winget, Chocolatey, or MSI line in the README, so the install path is the download page. The README lists the installer URL as https://download.fxsound.com/fxsoundlatest and the project website as https://www.fxsound.com.

Because the repository does not document a silent or scripted install, the honest instruction is to run the downloaded installer and follow its prompts. What you should see afterwards is the FxSound application plus the FxSound Audio Enhancer virtual audio driver, which the README says the application requires.

If you intend to build rather than only run the released binary, the prerequisites are listed in the README:

# Prerequisites listed in the README, not commands run here
# 1. Install the latest FxSound from https://download.fxsound.com/fxsoundlatest
# 2. Visual Studio 2022
# 3. Windows SDK
# 4. JUCE 6.1.6 for x64/x86
# 5. Latest JUCE framework for ARM64

With those in place, the README's build path is to open fxsound/Project/FxSound.sln in Visual Studio, choose a configuration and platform, and run. The repository also documents a command line options file at docs/COMMAND_LINE_OPTIONS.md, which is the place to look if you want to drive the application without clicking through the GUI. The README does not reproduce those options, so treat that file as the source of truth.

One debugging detail is easy to miss and will cost you time. If you launch from Visual Studio and the presets do not load, set the working directory for the FxSound_App project to:

$(SolutionDir)..\..\bin\$(PlatformTarget)

The README places this under Project, Properties, Debugging. Without it, the application runs from the wrong directory to find its preset data.

The driver dependency is the limitation that shapes everything

You cannot build a working FxSound from this repository alone. The README states plainly that the application requires the FxSound Audio Enhancer virtual audio driver, and that to run an application built from source you must install FxSound, because the installer is what deploys the driver. The driver source is not in the top-level entries listed here.

That has practical consequences. A contributor can change DSP behaviour, rebuild, and test, but only on a machine that already has the vendor driver installed. A packager cannot produce a self-contained FxSound build from this tree. And anyone hoping to study the full audio path end to end will find the device-level driver outside the code they have.

The platform constraint is just as firm. The README describes FxSound as built for Windows PCs, the prerequisites are Visual Studio 2022 and the Windows SDK, and the solution is a .sln. There is no macOS, Linux, Android, or iOS build path in the repository. If your target is anything other than Windows, this is the wrong tool, and no amount of reading the DSP code changes that.

How FxSound compares with Equalizer APO

The closest widely used alternative for system-wide Windows audio processing is Equalizer APO, which works as an Audio Processing Object loaded into the Windows audio stack and is configured through a text file of filters. The difference in approach is structural rather than cosmetic. Equalizer APO attaches to a specific audio device through the APO mechanism and is driven by a configuration file; FxSound ships its own virtual soundcard, its own JUCE-based GUI, and its own preset model, and the README frames the product around that digital-soundcard behaviour with clean passthrough.

That makes the two tools suit different people. If you want a filter graph you can version-control as text and attach per device, an APO-style tool fits better. If you want a graphical application with presets and a single system-wide processing stage, FxSound's model is the one described here. The trade-off is that FxSound's own driver and GUI are part of the deal, so you inherit its update cycle and its installer.

A second reference point is JUCE itself. FxSound uses JUCE, and the README notes that JUCE is licensed under AGPL v3.0. If you already build JUCE audio applications, the structure here will look familiar: a Projucer-exported solution with separate module projects.

Licence, releases, and what upgrading costs you

FxSound is licensed under AGPL v3.0, and the README links the LICENSE file. The AGPL's network clause is the part that changes decisions: if you modify FxSound and let users interact with it over a network, the licence's source-availability terms reach that deployment. Distributing a modified binary carries source obligations too. This is a description of the licence text, not legal advice, and anyone shipping a modified FxSound should read the licence and, where the stakes are high, take proper advice.

The release cadence visible in the repository is quick. Recent releases include Version 1.2.14.0, then Version 1.2.15.0 (Beta) on 2026-09-09, then Version 1.2.16.0 (Beta) on 2026-09-17. The last push to main was on 2026-09-17. Two of the three most recent releases carry the Beta label, so if you track releases you are partly tracking pre-release builds; pin to a non-beta tag such as 1.2.14.0 if you want the last stable-labelled version in this list.

Upgrade cost is mostly a Windows build cost. Each JUCE or Windows SDK change can force a rebuild, and the Projucer export path means redoing the manual solution edits described in the README: adding audiopassthru/audiopassthru.vcxproj and dsp/DfxDsp.vcxproj, adding the project references, and resetting the debugging working directory. That is a repeatable but manual chore, and it is the main tax on keeping a fork current.

Editorial conclusion

Adopt FxSound if you want a Windows-only system-wide audio processor and you are willing to install the vendor build first, because the application requires the FxSound Audio Enhancer virtual audio driver that the installer provides. Do not adopt it if you need Android, iOS, macOS, or a headless Linux pipeline; the README describes a Windows PC program and nothing else. Before building, verify that you have Visual Studio 2022, the Windows SDK, JUCE 6.1.6 for x64/x86, and the latest JUCE framework for ARM64, then confirm the working directory setting $(SolutionDir)..\..\bin\$(PlatformTarget) or the presets will not resolve at runtime.

Frequently asked questions

Official sources

1. fxsound2/fxsound-app on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases