Audio Signal Flow Planning

By VJ Ries · Published 2026-07-12 · Updated 2026-08-01 · 10 min read

Audio signal flow planning is the system-level documentation of how every audio signal travels from source to destination: mics and playback and comms into the console, through processing and buses, out to the PA, monitors, IEM/IFB, record, and any broadcast or stream feed. Plan it by inventorying every source and destination, mapping the main chain left to right, then drawing return paths like mix-minus and IFB explicitly instead of assuming them. Analog or Dante, the transport changes what the drawing must show. The goal does not: one diagram a stranger could patch and troubleshoot from.

What is audio signal flow planning?

What feeds what. In what order. And back to whom. Audio signal flow planning answers that one question for the whole rig. It is system-level documentation. Channel-strip tuning is a different concern.

Draw that path precisely and every downstream document follows from it: the cable schedule, the patch list, the gear list.

Treating the diagram as a picture of the mixer is the trap. Gain staging inside a single channel matters; it is still a knob-level concern. Planning is about topology. Which stagebox. Which console inputs. Which processing sits inline, and which returns exist. How audio crosses into video (embedders, de-embedders) and onto the network.

Same left-to-right discipline as the core AV signal-flow method, applied to the audio lane; the signal-flow best practices guide covers how the builder enforces it.

Step 1, Inventory every source, bus, and destination

List everything that carries audio before you draw, grouped by role.

Capture the connector or transport and the channel count for each. Those two facts decide how many cables and console inputs you actually need.

  • Sources: wired mics, wireless receivers, DIs, playback machines, computers, video-embedded audio, comms and phone lines
  • Input and console: stageboxes, preamps, the console surface or mix engine, plus any secondary mixer for broadcast, monitor, or overflow
  • Processing: dynamics, EQ, matrix, delay, effects, feedback suppression, and any loudness or broadcast processing on the program feed
  • Destinations: main PA and amps, delays and fills, IEM and IFB, stage monitors, broadcast and stream feeds, multitrack and archive recorders

Step 2, Map the backbone: sources to console to processing to destinations

Lay the backbone out left to right. Sources on the left. Console and processing through the middle. Destinations on the right. Keep one row per signal family where you can, and record which specific input each source lands on rather than a vague line into the console. The four stages below are the ones a good audio system diagram makes explicit.

The four stages every audio system diagram should make explicit
StageTypical devicesWhat the drawing must capture
SourcesMics, wireless RX, DIs, playback, comms, video-embedded audioConnector or transport, and channel count per source
Input / consoleStagebox, preamps, console surface or mix engineWhich console input each source lands on
ProcessingDynamics, EQ, matrix, delay, effects, broadcast processingInsert points, and which bus each process sits on
DestinationsPA and amps, IEM/IFB, monitors, record, broadcast/streamWhich bus or output feeds each destination

Generic box-and-line drawings fall down at the middle two stages.

A line from a mic into a rectangle labeled Console records an intention; recording that Handheld 3 lands on console input 11, gets a gate and a channel EQ, and sits in both the PA mix and the broadcast mix-minus records a buildable fact, the kind a port-aware tool stores connection by connection instead of as freehand lines you interpret at load-in.

Do the inputs and outputs actually fit?

Reconcile the counts before you call the drawing done.

Input and output totals are the cheapest failure to catch on paper and the most expensive to discover on the truck. Add up what the sources demand, then compare it to what the stagebox and console provide.

Do the sources fit the stagebox and console?
Wired mic and line sources: 16
Wireless receiver outputs: 6
Playback and comms returns: 4
Input channels required: 16 + 6 + 4 = 26
Stagebox analog inputs available: 24 (example figure, confirm against the model)
Shortfall: 2 inputs (26 required against 24 available)
Plan: add a second stagebox or a networked expansion before load-in, not during it

Channel capacities differ by model, and on networked systems they can shift with sample rate. Treat every count here as a placeholder to replace with the real device datasheet.

Run the same pass on the output side. Program, record, stream. Monitors, IEM, IFB, any overflow feed. Each one needs a bus and a physical output. Counting them now is how five destinations on a four-output matrix fail on the page instead of at the gig.

Step 3, Draw mix-minus and IFB as their own paths

Signal flows outward in a left-to-right diagram, so the drawing naturally tends to hide the feeds that flow back. Those return paths are exactly where remote and broadcast shows break. Draw each one as its own labeled path rather than trusting a reader to infer it.

  • Mix-minus: a bus carrying everything except one participant, sent back so a remote guest or phone caller does not hear themselves returned with delay. Each remote leg is usually its own mix-minus, so draw one path per leg.
  • IFB (interruptible foldback): the program-plus-talkback feed to on-camera talent or a host earpiece. Show three things as one explicit path: the program source, the talkback interrupt, the destination.
  • Monitor and IEM sends: separate mixes with their own buses and outputs. A stage-monitor path is not the same signal as the PA path, even when the content overlaps.
  • Confidence and comms returns: what the crew hears back, drawn so a stranger can see the loop close instead of guessing at it.

Analog or Dante? How the transport changes the drawing

Analog audio is one cable per signal. Diagram and cable schedule line up almost one to one. Networked audio like Dante carries many channels down a single link, so the drawing shifts from cables to subscriptions: which transmitting device and channel maps to which receiving device and channel, plus the switch and VLAN that carry them.

Both belong on the same system diagram; they just get documented differently.

Analog point-to-point versus networked (Dante) audio
AspectAnalog point-to-pointNetworked (Dante)
Physical runOne cable per signalOne network cable carries many channels
What the diagram showsEach XLR or TRS endpoint, drawn port to portLogical subscriptions (Tx device/channel to Rx device/channel) plus the switch
Channel capacityFixed by connector countMany channels per link, bounded by bandwidth and sample rate (check the device specs)
Failure modeOne cable down equals one signal downA switch or link down can drop many channels at once
How you label itCable ID plus signal nameDevice name plus channel label plus subscription

Because a networked failure takes down many channels at once, the underlying network deserves the same rigor as the audio. Capacity, clocking, QoS, switch setup: for Dante these are their own discipline, covered in Dante network requirements. The physical layer for the analog runs still becomes a cable schedule with real endpoints.

How do you document gain structure without guessing levels?

At the system level, gain structure documentation marks where level is set and where headroom lives. It does not publish a table of decibel targets you cannot verify.

The goal: anyone reading the diagram knows the reference points and can see where a signal could clip or run hot before it reaches the next device.

  1. Mark the reference points: preamp or input trim, any inserted dynamics, bus and matrix outputs, and the final stage feeding amps or the broadcast leg.
  2. Note the transport at each hop (mic level, analog line, AES, Dante) so nobody assumes a level the connector does not carry.
  3. Flag the crossings where scales change, especially analog to digital, where dBu and dBFS are different rulers and the alignment is device-specific.
  4. Record the intended operating reference for the system, such as the nominal level the broadcast feed should hand off at, and cite where you took it from.

Step 4, Walk every audio path before the truck rolls

Verify the diagram the way you would verify the system: trace each signal from source to final destination and confirm every hop is possible.

For each major path, ask a short list of questions.

  1. Does every connection land on an input or output that exists and is free, on the stagebox, the console, and the network alike?
  2. Is every transport transition handled: mic to line, analog to Dante, embedded to discrete audio out of the video switcher?
  3. Does every return path close? Is each mix-minus minus the right person, and does every IFB destination get program plus talkback?
  4. Do record, stream, and broadcast feeds survive if the main PA path dies? Where are the single points of failure, especially a shared network switch?
  5. Could a stranger build it: every device named, every input numbered, every cable ID and Dante subscription labeled, per labeling cables and ports?

In WireFlow the audio path is drawn on the same canvas as video and network. Signal tracing walks each path up and down. The verified diagram exports the gear list and cable schedule, so documentation stays consistent because it is derived, not retyped. The audio path tutorial shows the build in the app, and the whole packet goes to the crew as a shareable tech pack.

Frequently asked questions

What is the difference between audio signal flow and gain structure?
Signal flow is the routing. What feeds what, in what order, from source to destination. Gain structure is the level at each hop: how hot the signal runs and how much headroom is left before clipping. Signal flow planning documents the whole system topology; gain structure lives on top of it as level and reference-point notes at each stage.
Do analog and Dante audio go on the same diagram?
Yes. A real system usually mixes both, and splitting them across files hides the converters and interfaces where signal crosses between them. Keep everything on one system diagram, drawing analog runs port to port and networked audio as device-and-channel subscriptions plus the switch that carries them.
How do I document a mix-minus?
Draw it as its own labeled path. A note will not do. Show the bus that contains everything except one participant, and the return leg back to that participant. One mix-minus per remote leg, each drawn and labeled separately, so a stranger can see exactly who is subtracted from which feed.
How detailed should an audio system diagram be?
Detailed enough that anyone can patch or troubleshoot from it alone. Every source. Every console input. Every bus and output. Every return path. Summarize only what is genuinely atomic (you do not draw the inside of a stagebox). Will a human plug it, patch it, trace it? Then it belongs on the diagram.
Should I plan audio signal flow before choosing gear?
Sources, destinations, return paths: plan those first. They set your input and output counts and your bus needs. The counts then tell you what the console and the stagebox and the network have to support, which is a far cheaper way to catch a shortfall than discovering it after the gear is on the truck.

Build this diagram in WireFlow

Port-aware devices, validated connections, and exports your crew can read on site. Free plan includes three editable diagrams, no credit card.

Start a free diagram · Explore the sample show first