Audacious is a GTK, Qt and Winamp shell whose real contents are plugins with mixed licences

A core with three front ends

Audacious is described as a lightweight, open-source audio player focused on high audio quality and low resource usage, with a flexible plugin system for extending functionality. It runs on Linux, BSD derivatives, macOS and Windows, and the source is C++.

The three interfaces are the first thing to understand. There is a GTK interface, a Qt interface, and a Winamp interface with support for Winamp 2 skins. That is an unusual combination: the Winamp interface is not a retro curiosity bolted on for fun, it is a third complete front end that runs the same core, and anyone who came from the Winamp era can keep their skins.

The top-level layout describes a conventional C project with Meson. src/ holds the sources, contrib/ holds contributed pieces, po/ the translations, win32/ the Windows build, man/ the manual pages, plus images/ and a mkrelease.sh script. Two desktop integration files sit at the root, audacious.desktop and audacious.metainfo.xml, which is the packaging metadata a Linux desktop uses to list the application.

There is also a .clang-format file, which tells you the project enforces a single C++ formatting style in CI rather than leaving it to contributors.

The plugin system is not an extension point, it is the product

The README is direct about this: Audacious uses a modular plugin system to provide most of its functionality. Not most of its extensions. Most of its functionality.

That reframes the whole project. What you install is a shell that loads plugins, and the list of things the player can do is the list of plugins you enabled. It also means the boundary between Audacious and its plugins is where maintenance, licensing and risk live.

Plugins can be enabled or disabled at runtime from the settings window, and with the GTK or Qt interface several of them, the album cover, lyrics, file browser and visualizations among them, can be docked into the main window. So the plugin set is not a static build decision; it is a runtime configuration, and two people running the same binary can have materially different features.

The plugins that ship with the project live in a separate repository, audacious-plugins, which the README describes as officially provided and supported by the Audacious developers. Third-party plugins also exist, and here the wording changes: install and use them at your own risk. That sentence is the one to notice. An officially supported plugin has a maintainer answer to a bug report, and a third-party plugin does not, while both load into the same process.

Plugins are also enabled and disabled at runtime, which means a broken plugin can be removed without reinstalling anything.

Seven plugin types, and why the type matters

The plugin taxonomy in the README is short and each type has a distinct failure surface.

General plugins add features such as a lyrics viewer, last.fm integration and a playlist manager. Effect plugins apply audio processing: echo, equalizer, and speed and pitch. Visualization plugins draw things, the spectrum analyzer and VU meter being the named examples. Playlist plugins add playlist formats such as M3U, ASX and cuesheets. Transport plugins read from streams and file shares over HTTPS, FTP and SMB.

Two types decide whether the player works at all. Input plugins decode audio formats, with MP3, FLAC, Ogg Vorbis and Opus given as examples. Output plugins handle playback devices, with ALSA, PipeWire and PulseAudio named. A missing output plugin is not a degraded experience, it is silence, and on a machine where the audio stack has moved recently, that is the first thing to check.

This is also why the format list is conditional. The README says supported audio formats depend on enabled plugins, and then lists what typically includes MP3, FLAC, Ogg Vorbis, Opus, AAC and M4A, WAV, WavPack, Ad-lib chiptunes, audio CD, MIDI, Nintendo DS 2SF, PlayStation Audio, and tracker formats, ending with many more through FFmpeg.

Read that carefully. The first group is what Audacious decodes, and the last line is a different mechanism entirely: an FFmpeg based path that covers formats the native plugins do not. Two codecs with the same name in a bug report can be two different code paths.

Building with Meson, and the one file that explains every dependency

The build requirements are listed plainly: Meson, GCC or Clang, pkg-config, and the required development libraries for GTK or Qt, GLib, the audio backends and the codecs.

The reader who hits a missing dependency usually does so in the dependency requirements, and the README points at the answer before that happens. It suggests reading the project's own build pipeline, the install-dependencies script inside the GitHub Actions workflow, because that file contains the package names actually used on Ubuntu and macOS. A CI dependency script is a more reliable answer than any documentation list, because it cannot drift from the build without the build failing.

The build itself is three commands, out-of-tree in a build directory:

meson setup build      # pass custom build options with -D option=value
meson compile -C build # start building
meson install -C build # install the built software

Two companion commands are named for discovery. `meson configure build` lists every supported build option, and meson_options.txt holds the same information in a file you can read without running anything. That matters for a player with three interfaces, because which interface you build is a build option rather than a runtime choice.

Logs land in the meson-logs directory inside the build directory, which is where to look first when a configure step fails on a codec or a backend.

The Flatpak and the Snap are somebody else's problem

This is the paragraph most packages of Audacious never reproduce, and it is worth quoting in substance. Flatpak and Snap packages of Audacious exist, the README says, and then says the project neither provides nor supports them. If you have an issue with one of those packages, it says to make sure the same issue affects an ordinary installation before reporting it.

That is a support boundary stated in advance, and it has a practical effect on packaging decisions. A distribution package, a Windows installer, and Homebrew installation on macOS are all covered by the project's own instructions, with most Linux distributions providing Audacious in their repositories.

The same separation appears in the plugin story. Audacious and its officially provided plugin package are supported; third-party plugins and these packages are not. A useful heuristic when evaluating an Audacious install is to ask which pieces came from the project and which came from a packager, because the bug report path differs for each.

For troubleshooting, the README points at a common problems page on the project website, asks you to check you are on the latest version, tells you to enable verbose output with `audacious -V` on the command line, and reminds you to search the issue tracker including closed issues before filing.

audtool and MPRIS are how you drive it without the mouse

The feature list includes being controllable via MPRIS and with audtool, and that is more architecturally significant than it appears in a bullet point.

MPRIS is the standard desktop media player control interface, which means a desktop environment can show now playing information, respond to media keys and expose playback control without Audacious implementing anything specific. For a player whose selling point is low resource use and a long life on a machine, being a well-behaved MPRIS citizen matters more than most of the feature list.

audtool is the command line control, and it is what makes Audacity-style scripting and shell integration possible. Combined with a player that is already scriptable through its plugin configuration, an audtool-driven setup can start playback, change tracks and adjust volume from a keybinding or a script without a GUI event loop.

The other long-standing features in the list are worth naming for completeness: advanced playlist management, a built-in equalizer, audio effects and visualizations, support for ReplayGain, and gapless playback. ReplayGain in particular is the reason a player can be told to normalise volume across an album rather than between tracks, and gapless playback is the feature that makes a live album sound like an album.

Contributions go through pull requests for fixes and feature requests, the project forum, the issue tracker, and translation, which is managed on Transifex. The README asks that large changes open a forum thread first, and says plainly that the developers are volunteers with limited free time, which is a request for scoping rather than a disclaimer.

Editorial conclusion

Choose Audacious when you want a small player whose capabilities you assemble yourself, especially if you already use the Winamp skin ecosystem or need a player that will run on a machine without asking much of it. Do not choose it expecting a supported Flatpak or Snap, since the README states those packages are neither provided nor supported by the project, and read COPYING before redistributing a build, because the plugins carry their own licences. Verify first which output plugin matches your system, since ALSA, PipeWire and PulseAudio are separate plugins and the default choice is what decides whether audio works at all.

Frequently asked questions

Official sources

1. audacious-media-player/audacious on GitHub
2. Issues
3. Project website
4. README
5. Releases