goxlr-utility brings GoXLR configuration to Linux, macOS and Windows

The Rust workspace is split by hardware layer, not by feature

goxlr-utility is an unofficial tool to configure and control a TC-Helicon GoXLR or GoXLR Mini on Linux, macOS and Windows. The Cargo.toml defines a workspace with eleven members, and the member names describe the hardware stack from the bottom up.

There is usb/, which is the USB handler, and the workspace dependency list confirms it with rusb at 0.9.4, the Rust USB library. There is audio/, which handles the audio side. There is daemon/, client/ and ipc/, which together are the process structure, with the interprocess crate at 2.2.3 and byteorder for the wire format. There is profile/ for the profile handling, types/ for the shared types, initialiser/ for device setup, scribbles/ for scratch data, defaults/ for default configuration, and launcher/ for the entry point.

The message-passing choice is worth naming. interprocess is a cross-platform crate for local IPC, and using it rather than a socket means the daemon and client can talk over a Unix domain socket on Linux and a named pipe on Windows without the application having to care. Combined with tokio at 1.47.1 with the full feature set and futures, the daemon is an async service, which is what lets it hold a connection to the device and serve several clients at once.

The CLI is separate from the UI, and the workspace has clap at 4.5.48 with clap_complete, which is the shell completion generator. So the tool exposes its commands to the shell properly.

The workspace version is 1.2.4 with edition 2024, and the authors are Nathan Adams, Craig McLure and Lars Mühlbauer. The licence is MIT, and there is a LICENSE-3RD-PARTY file alongside the LICENSE, which is the right arrangement for a project that links a USB stack.

The web UI is served locally, and the same UI can be served to another machine

The interface design is the most interesting decision in the project, and it is unusual enough to explain.

The UI is web based and served directly from the utility to the web browser of your choice, and if configured it can also be served to a web browser on another computer. The project also provides an Application which wraps the web UI into a dedicated app, and on Windows that option is presented during installation.

The README says the UI design was modelled around the official application in an attempt to provide a familiar interface for those moving from Windows to other platforms, rather than forcing people to learn a new configuration paradigm. That is a deliberate choice about the users being served, and it explains why the utility has a Main and Mic profile pane layout that a GoXLR owner would recognise.

There is an accessibility claim attached, that the UI is accessible and designed to work well with assistive technologies. For a web UI that is a meaningful statement, and it is consistent with the rest of the design.

On Linux the Application is not part of the base installation. The README points to a separate GoXLR UI Repository which provides builds for distributions, and once installed you change the UI Handler under System -> Utility Settings. So on Linux the choice of a native window versus a browser is a configuration decision rather than a packaging one.

The remote access feature is what makes the web UI more than a convenience. Combined with the Remote Access entry in the features list, which says you can control your GoXLR from another computer on your network, it turns the utility into a remotely operable device service, which is also what the CLI and API are for.

Profiles from the official app import directly

The compatibility story with the official Windows application is the practical reason to try this tool, and it is handled in a way that costs the user nothing.

The features list says compatibility with profiles created by the official application. The import is a file operation rather than a conversion: you click the folder icon in the top right of the relevant profiles pane, either Main or Mic, which opens the directory in your file browser, you copy the profile across from the official app's directory, which is normally Documents/GoXLR, and they appear in the utility ready to load, with a double click.

That is a deliberate design choice with a consequence. The utility does not import a proprietary profile format; it reads the same files the official app writes, in the same place. So there is no translation step to get wrong, and a profile that works on Windows works here. It also means the utility is not creating a second format that would need migrating later.

The other direction is handled by the Exit Actions feature, which includes saving profiles and loading other profiles and lighting. The GoXLR has a lighting system, and the utility can drive it as part of what happens on exit, so a profile change can be scripted to change the colours.

The rest of the feature list is what a streamer would recognise as missing from other tools. Full control over the GoXLR and GoXLR Mini, similar to the official app. A sample Pre-Buffer, which records audio from before you press the button, which is a real streaming feature rather than a mixer setting. Multiple Device Support, so you can run more than one GoXLR on one PC. Exit actions. A CLI and API for basic or advanced scripting and automation. And Streamdeck integration, through a separate StreamDeck Repository.

The integrations section lists third-party projects that hook into it, including twitchat for reacting to Twitch bits and donations, MacroGraph as a visual programmer for streamers, an OBS fader sync plugin for syncing pre-mix volumes to fader volumes, and a Home Assistant integration.

Downloads are per-platform, and each one has a caveat

The release page serves four package formats, and the README is careful about which platform needs what.

The .exe files are for Windows, and the .pkg files for macOS with both Intel and M1 based packages available. The .deb files cover Debian based systems, named as Ubuntu, Mint, Pop!_OS and similar, and the .rpm files cover Redhat based systems, named as CentOS, Fedora and similar. Arch users can install the goxlr-utility package from the AUR, and Windows users can acquire it through winget as well.

Then the footnotes carry the important parts. On Windows, the official device drivers provided by TC-Helicon are required. The README says that if you have the official app installed you do not need to do anything, otherwise you download the latest drivers from a linked update site, with a specific driver archive named in the text. So the application is unofficial but the drivers are not, which is an unusual arrangement and an honest one to state plainly.

For macOS the note is that support is still somewhat experimental, and the package may conflict with the existing GoXLR-MacOS project, as the two attempt to do the same thing in certain situations.

There are also three distro specific notes, each pointing at a tracked issue or a wiki page rather than carrying the answer in the README. Ubuntu 24.04 or a derivative such as Linux Mint has a linked issue. Running the Mix 2 firmware and seeing UCM errors has a different linked issue. Fedora Atomic or Bazzite users are sent to a wiki page with instructions.

The pattern is worth internalising: a hardware utility that talks to a device across kernel versions and distributions accumulates per-environment problems, and the project tracks them openly rather than claiming universal support.

First run is microphone setup, and the daemon needs to autostart

The getting started section is short and specific about the first thing to configure.

Once installed, you launch the utility from the GoXLR Utility item in your applications menu, which starts the utility and its configuration UI. The UI is then accessible via the system tray icon, or, if you do not have a tray, by re-running the same menu item.

On Linux, the first configuration step should be enabling Autostart on Login via System -> Settings. Windows users get the choice during installation and can change it later. That detail matters more than it looks, because the daemon holds the connection to the device, and if it is not running when the application starts, the configuration you are editing may not be talking to the hardware.

For a fresh setup, the README says the best place to start is configuring the microphone. You go to the Mic tab and hit Mic Setup to configure the microphone type and gain. It may be easier to configure if you first set the Gate Amount to 0, then reconfigure it once the mic is working. That is a practical piece of advice about the order of operations, since gate amount changes how the mic behaves while you are still working out the gain.

After that, the README says to go explore the UI.

For the unofficial status, the disclaimer is explicit: the project is not supported by, or affiliated in any way with, TC-Helicon, and for the official GoXLR software you should refer to their website. The project also accepts no responsibility or liability for use of the software or for problems arising from its use, and the README points at the LICENSE file for the details.

The repository also has an AI_POLICY.md and a ROADMAP.md, plus a 50-goxlr.rules file and a goxlr-wireshark-plugin.lua, which are hints about the level of internal tooling around the USB protocol.

MIT licensed, three maintainers, and releases every few months

The licence is MIT, with the LICENSE file in the repository as the authoritative text, and this is a licensing statement rather than legal advice. There is a separate LICENSE-3RD-PARTY file, which tracks the licences of the vendored and linked dependencies.

The recent releases are v1.2.4 on 2026-02-23, described as small fixes, v1.2.3 on 2025-10-13 with fixes and features, and v1.2.2 on 2025-04-16 with a couple of maintenance fixes. The repository is not archived and the last push was on 2026-09-18.

The release titles are worth reading for what they reveal. Small fixes, fixes and features, a couple of maintenance fixes. That is the vocabulary of a mature utility that is not trying to add big features, which fits a project whose scope is defined by what the hardware can do and by what the official application does.

The version number in Cargo.toml is 1.2.4, matching the release tag, and the workspace is on edition 2024, which is current Rust.

The authors list has three names, which is a healthy number for a project of this type. The support channel is a Discord server, and the README calls the tool unofficial in its very first line, which is the kind of clarity that keeps expectations right for a hardware utility.

The primary language is Rust, and the dependency list shows the parts of the stack that are specific rather than generic. include_dir at 0.7.4 for embedding static files, image at 0.25.8 for the logo and icon handling, fancy-regex at 0.16.2 for the regular expressions the filters need, which crate at 8.0.0 for locating binaries on the PATH, sysinfo for system information, reqwest for web requests, winreg and the windows crate for the Windows specific parts, and nix at 0.30.1 for the Linux specific ones.

Editorial conclusion

Adopt goxlr-utility if you own a TC-Helicon GoXLR or GoXLR Mini and want to configure it on Linux or macOS, or on Windows without the official application. Do not adopt it if you need vendor support, since the project states it is not supported by or affiliated with TC-Helicon in any way. Before you install, check the per-distribution notes in the README, because Ubuntu 24.04 derivatives, Mix 2 firmware with UCM errors, and Fedora Atomic or Bazzite each have a linked issue or wiki page, and on Windows you need the official TC-Helicon drivers even though the application itself is unofficial.

Frequently asked questions

Official sources

1. GoXLR-on-Linux/goxlr-utility on GitHub
2. Issues
3. License: MIT
4. README
5. Releases