When it misbehaves.
The community’s running list of odd behaviour, and what actually fixes each one.
Symptom, cause, fix
This is the accumulated list of things people have run into. Most of them are not bugs in the Utility at all — they’re the audio stack, the desktop session, or a default nobody expected.
| Symptom | Cause | Fix |
|---|---|---|
| Latency | PulseAudio handles the GoXLR badly. | Switch to Pipewire. |
| Audio stuttering | Certain AMD motherboard and CPU combinations. | Update your BIOS firmware. |
| No audio from Line Out | The Utility’s default profiles ship Line Out at 0%. | Raise the Line Out level. Nothing is broken. |
| Stuttering or dropouts | Wayland session. | Switch to X and retest. |
| Device misbehaves generally | A Thunderbolt dock with its own built-in audio. | Run usb_modeswitch -d against the dock’s built-in audio device. |
| Device disappears | Initialisation glitch. | systemctl --user restart pipewire |
| Mic is permanently silent | The noise gate. | Mic tab → Gate, disable it, retest. |
| Everything sounds quiet | Pipewire sometimes sets channels to 40%. | Open pavucontrol and set all channels to 100%. |
Include your OS and version, the Utility version, whether it’s a full-size GoXLR or a Mini, and what the daemon logged. Nearly every reply on the tracker opens by asking for exactly those four things, so leading with them saves you a round trip.
Still stuck
The issue tracker is the place for reproducible bugs; search it first, because first-run problems are almost always already there. The Discord server is better for the setups that aren’t quite standard and the questions that aren’t quite bugs.
Written from the GoXLR Utility project’s own documentation (Reported Weirdness) and reproduced here in our own words, so you don’t have to leave the site. The project’s originals remain the authority if anything here goes stale.