openmixerGitHub →

The main output is silent

Symptom

Channels have signal. The channel meters move. The main meter moves. Nothing comes out of the speakers or headphones.

The moving main meter is the important detail: it means the mix is being made and the problem is on its way out of the desk, not inside it.

Most likely cause: the main output is not routed to a live sink

The main mix has to be routed to a real PipeWire sink, and that route is stored by name, not by whatever happened to be device number three last week.

Two things break it:

  • The sink is not there. An interface that was unplugged, a USB card that re-enumerated, a Bluetooth device that disconnected.
  • The sink is there but its ports are not. An audio interface presents different ports under different profiles — an RME running its pro-audio profile has completely different port names from the same card running plain analog stereo. A route saved against one profile refers to ports the other does not have.

openmixer follows the device's active profile when it lays routes, so a saved …analog-stereo route on a card now running its pro profile is remapped rather than left dangling. What it cannot do is invent a port: a device whose active profile has no equivalent output at all is genuinely unroutable, and that is the case that stays silent.

Fix

  1. Open the Patchbay chip.
  2. In the output routing row, find Main.
  3. Re-pick the sink you actually want to hear.

If the sink you want is not in the list, the device is not presenting outputs. Check the card's profile — for an interface with a pro/DAW profile, check whether the mixer is looking at the profile you think it is — and check that the device is not being held by another application.

Second cause: something else owns the card

If another application has the output device, the mixer's route can be laid and still produce nothing.

pw-top
pw-link -l | grep -i <your device>

The console takes exclusive control of the device sinks by default — severing every non-mixer application link while leaving those applications visible in the patchbay for manual patching. The preference is /patchbay/exclusive wanted, switched from Setup > Patchbay; an application the operator marks leave-alone keeps its own route through the takeover. On a shared desktop, switch it off there.

Third cause: the obvious ones

Check them, in this order, because they are quick:

  • MAINS MUTE or ALL MUTE in the header. They are panic buttons and they do not ask for confirmation.
  • The Main fader itself, and the main mute.
  • A matrix or output insert chain on the main output — a limiter with its threshold at the floor, a crossover routing to nothing.
  • The physical amplifier or monitor.

If the sinks are muted at the operating system after a restart

The desk keeps the house silent while the engine is down. Two hooks on the openmixer-server unit do it: the stop hook mutes every sink the console was feeding milliseconds after the process dies (it runs on a crash too), and the start hook gives them back only after the console has answered and re-laid its routes.

So a house that is silent after a restart, with the console's own meters moving, is the start hook reporting that it never got an answer. It leaves the sinks muted on purpose — an unmuted sink with no console behind it plays whatever a browser tab is holding into the room. It also says which sinks it is holding:

journalctl --user -u openmixer-server -b | grep gig-safe
gig-safe: http://127.0.0.1:8800/health did not answer in 60 tries (up to 180s); sinks held muted: alsa_output.usb-RME_Babyface_Pro-00.pro-output-0

The sinks are the symptom, not the fault: the console is not answering on the port the hook asked. Find out why the console is down (systemctl --user status openmixer-server), fix that, and restart the unit — the start hook unmutes on the first health poll that answers. To hear something before then, unmute the named sink by hand:

pactl set-sink-mute alsa_output.usb-RME_Babyface_Pro-00.pro-output-0 0

Nothing is stopping the desk from starting either way: the hook's failure is recorded and ignored, never propagated to the unit.

If it started after a restart

A restart tears the PipeWire links down along with the processes. The mixer re-issues its routes by name when it comes back, and an event-driven heal re-issues them again as ports register, which covers a device that enumerates late. If Main is still silent a minute after a restart, the route is not being lost — it is not resolvable. Go back to the top of this page.

If the console comes back broken after every restart

That is a different problem: see a poisoned autosave session.