Skip to content

Connect and Manage Bridges

Bridges connect livematrix to an audio interface such as an analog interface, Dante Virtual Soundcard, or a physical Dante interface. Use Server (built-in) when the interface is connected to the server. Install the standalone bridge on another computer when its interface is elsewhere.

Open Bridges, enable the built-in bridge or connect a standalone bridge, and select Add line. Each bridge line has one target and an optional input leg, output leg, or both:

  • Input sends one hardware channel into the target.
  • Output plays the target’s mix-minus return on one hardware channel.
  • Enabling both makes a four-wire. The two legs may use paired sides of the same interface or different devices.

Choose the audio device and its channel for each leg. Channels are numbered from 1 in the interface. Test tone replaces an output’s received audio so you can check the hardware path without changing what the line is connected to.

The target picker lists users, party lines, and feeds directly. A line does not need a separate port or preparatory object. A standalone bridge carries all of its bridge lines over one encrypted WebRTC connection, so adding, changing or removing one line does not interrupt the others. Only a lost connection interrupts every line of that bridge until it reconnects.

A bridge line targeting a user acts as one more device of that user. Its output plays the user’s mix. Its input talks as the user.

All of a user’s devices share one microphone. A sole live bridge input becomes the microphone automatically. Connecting or renegotiating a bridge does not take the microphone away from another live device. If another device owns it, the bridge input is gated; use Take over mic once when you intend to move ownership to the bridge.

A bridge line targeting a party line contributes its input to that line and plays the other contributors on its output. It never returns its own input. Two bridge lines on the same party line are separate participants, so each hears the other.

A feed works the same way for bridge hardware: an input contributes audio and an output monitors all other contributors without returning itself. Feed keys in the app remain listen-only.

Each leg that is on has a gain fader, from −60 dB to +24 dB, with a number field beside it (0.1 dB steps) and a reset to 0 dB. The input gain sets how loud the hardware channel reaches its target; the output gain sets how loud the line plays on its hardware channel, test tone included. The change is saved and heard as you drag: the line keeps running, and no other line is touched.

Under each fader a meter shows the leg’s level after its gain, with a peak hold. Two dots at its end light for a few seconds when the leg clips:

  • Red — clipping after the gain. Lower the fader.
  • Amber — clipping before the gain: the signal arrives at full scale already. Lower the source (the interface’s preamp, or whatever feeds the line); the fader cannot fix it.

A dimmed meter means the leg is not measured: it is not running, or, on an output, its audio has not arrived yet. The line’s status says why. Meters of the built-in bridge are shown in the management UI, and a standalone bridge’s in its own web UI; for a standalone bridge the management UI shows the faders without meters.

When the operating system reports the capture and playback sides of one interface as a pair, choosing the input side preselects its playback side for the output, even while the output leg is off. An output you selected explicitly is never replaced, and channels are never chosen for you. On Windows, the computer’s own built-in devices and loopback (recording of an output) devices are never paired. Check the device and channel on both legs before saving.

Each row reports the running state of its input and output. A missing target, unavailable device, licence refusal, or media failure stays on that line. Other lines on the same bridge remain connected.

  • Refused means the server turned the line down, usually because the licence has no free ports. The row shows the reason and a Retry button.
  • Target missing means the user, party line, or feed it targets was deleted. The line keeps its settings; select another target, disable it, or delete it.

Nothing retries a refused line on a timer. It is tried again when you press Retry. The built-in bridge also tries every refused line again whenever its lines change; a standalone bridge does when that line’s target or legs change, or when the bridge reconnects. A missing or failing audio device is different: the bridge retries it by itself.

Every enabled bridge line with a target uses licence ports while it runs, on the built-in bridge exactly as on a standalone one. A line targeting a party line or feed uses one port per leg: one for input, one for output, two for a four-wire. A line targeting a user counts as one more device of that user. The test tone uses no extra port. See Licence.

Guard a bridge key like an administrator credential. Anyone who can edit a bridge’s lines, including through the bridge’s own web UI, can route audio to users and lines that the bridge can see.