Signal Flow & System Architecture

Introduction

Every technician eventually walks into a room full of equipment they did not install, is handed a problem nobody can explain, and has twenty minutes before doors. The ones who cope are not the ones who know the most equipment. They are the ones who can look at a rack, a stage box and a tangle of cable and see where the signal starts, where it is supposed to go, and every place it passes through on the way.

That is signal flow, and it is the one skill in AV that does not change when the brand does, when the discipline does, or when the system moves from copper to a network. A microphone into a speaker, a laptop into an LED wall, a lighting console into a moving light and a remote guest into a live stream all obey the same logic. Learn to follow it and every system becomes readable.

What this book covers

The source-processing-destination model and the kinds of signal a system carries; what actually travels down each cable, from mic level to SDI to serial control; tracing a signal through patch bays, splits, inserts and returns; keeping level right from the first stage to the last; the boxes that convert, extend and negotiate a signal on the way; how whole systems are built around a core; how signals move on a network where the cable no longer shows the route; audio, video, lighting, comms and control as one way of thinking; drawing and reading system documents; and finding any fault by following the flow.

It was measured against the certification outline for general AV technicians, the standard texts on sound systems and AV technology, manufacturer training on video, control and networked audio, and the published standard for verifying an AV system, so that nothing a technician is taught elsewhere about signal flow is missing here.

Who this is for

Anybody who has finished AV Fundamentals 101, or who has spent enough time on crews to know what a source, a console and a switcher are for. It assumes the words and teaches what to do with them.

How to Use This Book

Each chapter follows the same shape, and the shape matters more than it might look. You read the ideas, then you see them play out in a real situation, then you get the procedure, then you are shown what goes wrong and how to recognise it early. Reading only the parts that look new is the fastest way to arrive on a job holding half of something.

1. Read the chapter body first. This is the understanding layer, and it is written to be read straight through.
2. Read On the job. The same material as a real situation on a real show, which is where it stops being abstract.
3. Work through How to do it. These are procedures you can follow on a job this week.
4. Study What goes wrong. Experienced technicians are not people who never make mistakes; they are people who recognise mistakes early.
5. Do the exercise before reading the answer key. Recognition feels like learning and is not.
6. Take the checklist with you. Photograph it on your phone. Use it until you no longer need it.

Keep a notebook

One habit is worth starting today, before the first chapter: keep a small notebook and draw in it. Every system you work on, sketch as boxes and arrows, sources on the left and destinations on the right, with the cable numbers, the patch points and the settings that mattered — the input a laptop is on, the level the stage box is sending, which device is the clock leader, which output feeds the stream.

Draw it by hand rather than photographing somebody else's drawing. Copying a drawing puts it on paper; drawing the system yourself is what puts it in your head, and deciding where each box goes is most of the understanding.

Then use it twice. Look through a few pages on the way to a job, which takes five minutes and turns systems you half-remember into systems you know. And carry it on the job, because the patch you cannot remember is always the one somebody is waiting for.

A note on the words

Signal flow vocabulary changes between audio, video, lighting and IT, and between countries and manufacturers, and it is worth expecting that. A block diagram is a flow diagram, a system diagram, a schematic or a line drawing depending on who drew it. A stage box is a snake, a stagebox or an I/O rack. Program is spelled the American way on a switcher because that is what is printed on it. The core of a system may be called the head end, the rack room or the control room. Dante still says leader and follower where older documents say master and slave.

None of that is worth arguing about. What matters is that you can say what a device or a connection does, because a person who can describe the function will be understood anywhere.

A note on safety

Signal flow work looks safe and mostly is, but it happens around things that are not. Speaker outputs carry voltages that can hurt, and a speaker driven by a signal pop can damage hearing and equipment at once. Phantom power is sent down microphone cables you are holding. Racks are heavy and tip. Every system you trace is plugged into mains power, and some of the hum faults in this book tempt people to defeat a safety earth, which can kill.

Nothing in this book authorises electrical work, and nothing in it ever involves removing or lifting a mains earth. When a fault leads you to the mains side of a system, it has left your hands and gone to a qualified person.

Where this book sits

This book assumes you have read AV Fundamentals 101, or that you already know what is in it.

Experience counts instead. If you have time on crews where you have already patched a console, plugged a laptop into a switcher, and know what a source and a destination are, start here.

If none of that is true yet, read AV Fundamentals 101 first.

What pairs with this

• Audio Basics — the audio chain, gear by gear, that this book traces
• Video Basics — the video chain, gear by gear, that this book traces

Where it leads

These are not steps in an order. Take whichever one fits.

• AV Troubleshooting Methodology — to turn tracing into a complete method for any fault
• Networking Basics — because more of every system now travels on a network
• AV Documentation & System Design Basics — to draw the systems this book teaches you to read

Before You Begin

The Source-Destination Model

Every signal, in every system, travels the same journey. Master it once, apply it everywhere.

Source, processing, destination

Every AV signal travels the same fundamental journey: from a source (where it originates), through processing (where it is shaped and routed), to a destination (where it is delivered). A microphone (source) feeds a console (processing) feeds a speaker (destination). A camera, a switcher, a display. A laptop, a scaler, a projector. The gear changes endlessly; the shape of the journey never does. This source-processing-destination model is the foundation of all AV, and holding it clearly in mind is what turns a confusing wall of equipment into a comprehensible flow.

This book takes that model — introduced in AV Fundamentals — and makes it a deep, working foundation. Because every signal in every AV system follows this path, understanding it thoroughly means you can make sense of any system, in any discipline, however complex. The model is simple, but its implications are profound: it underlies how systems are built, operated, and fixed. Everything else in AV is an elaboration of moving a signal from a source to a destination.

The same model everywhere

The power of signal flow is its universality: the same source-processing-destination model applies across every AV domain. In audio, a signal flows from mic to console to speaker. In video, from camera to switcher to display. In lighting, from console over DMX to fixture. In data and control, from device to device across a network. Even a whole show is many such flows overlapping. Learn to think in signal flow, and you can understand any AV system in any discipline, because they all obey the same fundamental logic.

This is why signal flow is the foundation everything else in AV rests on. Whether you specialise in audio, video, lighting, networking, or something else, you are working with signals flowing from sources to destinations, and the thinking is the same. Mastering signal flow deeply here means every discipline-specific book makes more sense, because you already understand the underlying flow they each elaborate. Signal flow is the common language of all AV.

Devices that do more than one job

The model sorts devices into three buckets, and the first real system you meet will contain boxes that refuse to stay in one.

A powered loudspeaker is an amplifier and a destination in one cabinet. A camera with a card slot is a source and a recorder. A laptop is a source of slides, a destination for a video call and, with the right software, a processor. A digital console is processing, but its stage box is where the microphones enter, and its USB port may be a source of playback and a destination for a recording at the same time. A meeting room's all-in-one video bar is a camera, microphones, a loudspeaker and a codec in a single slab.

None of this breaks the model. It means the model applies to what a box is doing on a particular signal, not to the box. Ask which job the device is doing for the signal you are tracing right now. For the presenter's voice, the video bar is a source. For the remote guest's voice, the same bar is a destination. Trace one signal at a time and each device has one role on that path.

This is also why labelling a device by its category in your head can mislead you. A switcher is usually processing, but a switcher with a built-in scaler, audio de-embedder and recorder is four stages in one box, and a fault can be in any one of them. When a device does several jobs, draw it as several boxes.

What a signal is, and the kinds a system carries

A signal is information travelling from one place to another in a form a device can use. The picture on a screen and the voice in a speaker are the obvious ones, and they are only part of what a working system carries.

Content signals are what the audience experiences: audio and video. Control signals tell devices what to do: a lighting console telling a fixture to move, a touch panel telling a projector to turn on, a switcher telling a camera its tally light should be red. Data is the general traffic of a network, which may be carrying any of the others. Sync signals carry time: a clock that keeps digital audio devices sampling together, a reference that keeps cameras and switchers building frames at the same instant, and timecode that tells playback, lighting and recording where in the show they are.

Every one of these follows the model. A touch panel is the source of a control signal, a control processor is its processing, and the projector is its destination. A clock generator is a source, a distribution amplifier spreads it, and every device that locks to it is a destination.

This matters because a system can have perfect content wiring and still fail. A projector that is correctly patched will show nothing if the control command to switch its input never arrived. A digital console with every microphone connected will click and crackle if its clock is wrong. When you trace a system, trace all of its signals, including the ones nobody put on the drawing.

Power is not a signal. It travels through a system in its own distribution, it has its own rules and its own qualified people, and it is not traced the way a signal is. But a device with no power is a stage where every signal stops, so power is always the first thing you check.

Signals that travel both ways

The simplest chains run one way: microphone to console to speaker. A growing share of the connections in a modern system carry signals in both directions at once, and the idea of upstream becomes a question you have to ask separately for each direction.

An intercom beltpack sends the operator's voice to the base station and receives everyone else's back on the same cable. A network cable carries traffic both ways. A USB cable from a meeting room computer to a video bar carries the camera and microphones to the computer and the far end's voice back to the loudspeaker. An HDMI cable carries video one way and, on thin wires inside the same cable, sends information about the display back the other way. A camera cable to a control unit carries the picture down and the return feed, tally and the director's voice up.

A return feed is the general name for a signal sent back towards a source: the program picture sent to a camera operator's viewfinder, the mix sent back to a remote presenter, the playback sent to a stage monitor. Return feeds are easy to forget because they flow against the direction everybody draws.

When you trace a two-way connection, trace each direction as its own chain. If a remote guest can hear the room but the room cannot hear the guest, the cable, the computer and the network are all proven good in one direction, and the fault is somewhere on the other path only. That single observation halves the search before you have touched anything.

Sorting a system into the model

The same devices, sorted by the job they do on one signal. A device can appear in more than one row when it does more than one job.

The kinds of signal a system carries

• Audio — what the audience hears.
• Video — what the audience sees.
• Control — commands that make devices act.
• Data — network traffic, which may carry any of the others.
• Sync — clock, reference and timecode, which keep digital devices in time.

On the job

A hotel ballroom, the morning of a sales conference. You have been sent to cover a technician who went home ill, and the system was installed by someone else yesterday. There is no drawing.

The client's first request is simple: the keynote speaker wants to see her slides on a confidence monitor at the front of the stage. The monitor is there and plugged in. It shows a blue screen.

You do not start swapping cables. You stand at the back of the room and sort what you can see into the model, for the one signal that matters: the slides. The source is a laptop at the lectern. The main screen shows the slides, so the laptop, its cable and whatever sits between it and the main projector are all proven good. Somewhere after that, the signal is supposed to branch to the monitor.

You follow the laptop cable to a small switcher under the stage, and see that it has two outputs. One goes to the projector. The other runs to the confidence monitor. So the switcher is the point where the path splits, and everything upstream of it is good.

The monitor's cable is plugged into output two. The switcher's front panel shows output two assigned to input three, an empty input. Yesterday's technician tested it with a different laptop. You route input one to output two and the slides appear.

It took four minutes, and you never touched a cable. Everything you did was sorting devices into source, processing and destination, and asking what was already proven good.

How to do it

1. Pick one signal that matters and say it out loud — the presenter's voice, the slides, the stream.
2. Find where that signal starts. That is the source.
3. Find every place it is supposed to end. Those are the destinations.
4. Walk the path between them and list every box and connection, in order.
5. Mark each device with the job it is doing for this signal, drawing a multi-job device as several boxes.
6. Mark what is already proven good by what you can see and hear working.
7. Repeat for the next signal, including control, sync and anything travelling in the other direction.

What goes wrong

Practice it

Answer before checking.

What Travels Down the Wire

Tracing a signal means knowing what the signal is at every point. A microphone cable, a speaker cable and a guitar lead can all end in similar connectors and carry wildly different signals, and plugging one into the wrong place is the commonest way a correctly traced system still fails.

This chapter goes cable by cable through what a technician meets: the audio levels and why they differ, balanced and unbalanced lines, impedance at the depth a patch needs, digital audio, video signals, control and sync. It is not a catalogue of connectors. It is what the signal is, so that you know what each stage expects to receive.

Mic, instrument, line and speaker level

Audio signals travel at very different strengths depending on where they are in the chain, and every input is built to expect one of them.

Mic level is the weakest. A microphone produces a tiny voltage, and a console's microphone preamp has to add a great deal of gain before it can be used. Instrument level comes from an electric guitar or bass pickup: stronger than a microphone, but produced by a high-impedance source that loses high frequencies and picks up noise over any real distance, which is why it goes into a DI box before it goes anywhere near a stage box. Line level is what equipment sends to other equipment: a console's outputs, a playback device, a processor. Speaker level is the output of an amplifier, many times stronger again, carrying enough power to move a loudspeaker cone and enough voltage to hurt you.

The levels are measured in decibels against a reference, and the letters after dB say which reference. dBu is measured against 0.775 volts and is how professional equipment describes its analog levels; professional line level is usually +4 dBu. dBV is measured against one volt and is used for consumer equipment, whose line level is usually −10 dBV, noticeably lower. dBFS means decibels relative to full scale, and it only exists inside digital equipment: 0 dBFS is the largest number the converter can represent, every real level is below it and written as a negative number, and anything that tries to go above it is clipped flat.

The practical consequences are simple and constant. A line level output into a mic input overloads the preamp, and it distorts no matter where the fader is, unless the input has a pad or its gain can be turned right down. A mic into a line input is barely audible and, when somebody turns it up to compensate, noisy. A consumer device into a professional input is quiet, which tempts people to fix it with gain at the wrong stage. And a speaker output must never be connected to any input at all.

Balanced and unbalanced lines

Every cable is an antenna. Along its length it picks up interference from mains cables, lighting dimmers, radio transmitters and anything else nearby, and an audio signal that is small to begin with can be buried by it.

An unbalanced line carries the signal on one conductor and uses the shield as the return. Any noise picked up along the way is simply added to the signal, and the longer the run the more there is. Guitar leads, consumer phono cables and headphone cables are unbalanced, and they are kept short for this reason.

A balanced line carries the signal twice, on two conductors, with one copy inverted in polarity, inside a shield. Along the run, both conductors pick up the same noise, because they are twisted together and sit in the same place. At the input, a differential stage inverts one copy back and combines them. The two copies of the signal add together. The two copies of the noise, which arrived identical, cancel. Noise that appears equally on both conductors is called common-mode noise, and rejecting it is the entire point of a balanced line.

This is why a microphone can run fifty metres to a stage box and stay clean, and why professional line level outputs and inputs are balanced. On an XLR connector the widely followed convention is pin 1 for the shield, pin 2 for the signal in normal polarity, usually called hot, and pin 3 for the inverted copy, usually called cold. On a TRS jack the tip is hot, the ring cold and the sleeve the shield.

Balancing only works if both ends are balanced and the cable in between has both conductors connected. An adaptor that turns an XLR into a mono jack, or a TRS output plugged into a TS lead, quietly unbalances the line: the signal still arrives, a little quieter, and the noise rejection is gone. On a short patch you will not hear it. On a long run next to a dimmer rack you will.

Impedance, as much as a technician needs

Impedance is how much a circuit resists an alternating signal, measured in ohms. Designers calculate with it. A technician on a patch needs only two practical ideas from it.

The first is bridging. Modern line outputs have a low output impedance and line inputs have a much higher input impedance, commonly ten times or more. Connected like that, the input takes almost nothing from the output, which means one output can feed several inputs at once without the level dropping noticeably. That is why a console's matrix output can be split with a Y cable to a recorder and a delay processor. The reverse is not true. Two outputs joined into one input fight each other, the level drops, the sound distorts, and the output stages can be stressed. Joining signals together is what a mixer is for.

The second is loudspeaker load. An amplifier channel is rated to drive loudspeakers down to a minimum impedance, often 4 or 8 ohms, and every loudspeaker has a nominal impedance of its own. Loudspeakers connected in parallel on one amplifier output lower the total impedance: two 8 ohm cabinets together present 4 ohms, and four present 2. Below the amplifier's rating it overheats, protects itself by shutting down, or fails. So the number of cabinets hung off one amplifier channel is not a free choice on a patch. It was decided by whoever designed the system, and it is written on the drawing.

The instrument DI box sits across both ideas. A guitar pickup needs to see a very high input impedance or it loses its brightness, and it cannot drive a long balanced line. A DI box presents the high impedance the guitar wants and delivers a low impedance, balanced, mic level signal the stage box wants.

Digital audio on a cable

Once audio has been converted to numbers, a cable carries data rather than a voltage that looks like the sound, and the rules change.

AES3, often simply called AES or AES/EBU, carries two channels of digital audio on one balanced cable, usually with XLR connectors. It looks exactly like a microphone cable, and ordinary microphone cable will often carry it over a short run, but the format is built for 110 ohm cable and long or marginal runs on the wrong cable produce dropouts. Its consumer relation, S/PDIF, carries the same kind of data on coaxial phono or optical connectors over shorter distances.

MADI carries many channels on a single coaxial or fiber connection — up to 64 channels in common use — and is how consoles, stage racks, recorders and broadcast trucks moved large channel counts before networked audio became common. It is still widespread in broadcast.

Audio also travels inside video. An SDI or HDMI signal carries audio channels alongside the picture, which is why the sound can disappear when a picture passes through a box that does not pass its audio on.

A digital link behaves differently when it fails. An analog cable that is damaged gets noisy or crackles, and you can hear the fault getting worse. A digital link is perfect until it is not, and then it clicks, drops out or goes completely silent, with very little warning in between. That cliff edge is also why digital devices have to agree on a clock, which comes later in this chapter.

Video signals and what each one is for

Video connections look like a list of connectors, and each is really a set of rules about distance, locking and what travels with the picture.

SDI, serial digital interface, is the professional video signal. It runs on 75 ohm coaxial cable with BNC connectors, which twist and lock so they cannot be pulled out by a passing foot, carries embedded audio and timecode, and runs much further than consumer formats — around a hundred metres of good cable at common HD rates, less at higher rates. The versions are named for the data they carry: 3G-SDI for full HD, 12G-SDI for UHD. SDI is one-way, has no copy protection and no negotiation, and is what cameras, switchers, routers and broadcast equipment use.

HDMI is the consumer and presentation signal. It carries video, audio and, in the other direction, information about the display. It does not lock, it does not run far on ordinary passive cable — around fifteen metres is a practical limit, less at high resolutions — and it carries copy protection and a handshake that SDI does not. Laptops, media players, consumer cameras and most displays use it.

DisplayPort and USB-C carry similar signals from computers, over even shorter passive cables, and are usually converted to HDMI close to the source.

HDBaseT is not a connector but a way of carrying video, audio, control and sometimes network and power over one category cable, up to around a hundred metres, between a transmitter and a receiver. It is how HDMI gets from a lectern to a projector in a ceiling.

Legacy analog video — VGA, composite, component — still turns up in older venues. It degrades gradually with distance rather than failing outright, and it has no audio.

The connector tells you the family. It does not tell you whether two devices will agree, and the next section is why.

Resolution, frame rate and format travel with the signal

A video signal is not just a picture. It is a picture in a particular format: a resolution such as 1920 by 1080, a frame rate such as 50 or 59.94 frames per second, a scan type, progressive or interlaced, and a colour format. Every one of those travels with the signal, and every device on the chain has to accept it.

Two devices that both say SDI on the back will still refuse each other if one sends 1080p at 59.94 and the other only accepts 1080i at 50. The cable is correct and the picture is black, or rolling, or intermittent. The same happens on HDMI when a source sends a resolution the display cannot show.

So a video signal flow is always two questions. Is the signal getting there, and is it in a format the next stage accepts? The first is traced with cables. The second is traced with menus, and on a show the answer is written down once for the whole system: the show format. Every camera, switcher, recorder and processor is set to it, and anything arriving in another format is converted at the edge of the system rather than wherever it happens to appear.

Audio has the same idea in a quieter form. Digital audio devices have to agree on a sample rate, commonly 48 kHz on shows and in video, and a device at 44.1 kHz on a 48 kHz system either refuses to connect or clicks.

Control signals

Control signals are how one device tells another to act. They are small, slow and easy to overlook, and a system full of perfectly patched content will do nothing if they are missing.

Serial control, usually RS-232, sends text or numeric commands over a few wires, typically from a control processor to a projector, display or matrix. It runs short distances, around fifteen metres, and needs the settings at both ends to match. Its relation RS-485 runs much further and can connect several devices on one pair.

Infrared control imitates a remote control. A small emitter is stuck over a device's IR sensor and flashes the same codes a handheld remote would. It is one-way, so the control system never knows whether the command worked.

Relays and contact closures are the simplest control of all: a switch closing or opening. They lower motorised screens, trigger a lift, fire a cue light or tell a system a door has opened. A general-purpose interface, GPI, is the broadcast name for the same idea.

IP control sends commands over the network, and is now how most processors, cameras, displays and matrices are controlled. It is invisible on a cable and can be traced only in software.

DMX512 is the lighting control signal: a one-way stream of 512 channel values, called a universe, sent from a console to fixtures daisy-chained one after another, traditionally on five-pin XLR connectors and 110 ohm data cable. It looks like a microphone cable and should not be run on one.

The one habit that matters is to trace the control path as a separate chain. A touch panel is a source; a control processor is processing; the projector, the screen motor and the camera are destinations. When a button does nothing, the fault is somewhere on that chain, and the video cable is not on it.

Sync — clock, reference and timecode

Digital equipment works in steps: audio samples, video frames. When two digital devices pass signals between them, their steps have to happen at the same instants, and something has to set the pace.

In digital audio, that something is the clock. Every device either generates the clock or follows one. A dedicated connection called word clock carries it on a BNC cable, or the clock is taken from an incoming digital audio signal, or it travels on the audio network. When two devices disagree on the clock, samples are occasionally dropped or repeated, and the result is a regular click or a crackle that sounds like a bad cable.

In video, the equivalent is reference, often called genlock or sync. A sync generator sends a reference signal — black burst or tri-level sync — to cameras, switchers and processors, so that every frame from every source starts at the same instant. Without it a switcher has to buffer and re-time each source, which adds delay, and some cuts glitch or roll.

Timecode is different. It does not set the pace; it labels the moments. It is a running clock of hours, minutes, seconds and frames that tells recorders, playback, lighting and show control where in the show they are, so that a cue can fire at the same moment every night and recordings from different devices can be lined up afterwards. It is sent as an audio-like signal called LTC, as MIDI timecode, or on the network.

Sync signals follow the model like any other. There is one source, which is the whole point: a system with two clock leaders is a system with a fault.

Audio levels at a glance

Approximate levels a technician meets. Real devices vary; the order of magnitude is what matters on a patch.

Video signals compared

Typical figures. Real distances depend on cable quality, resolution and the equipment at each end.

Control and sync signals

XLR pins, by the common convention

• Pin 1 — shield.
• Pin 2 — hot, the signal in normal polarity.
• Pin 3 — cold, the inverted copy.

On the job

A product launch in a converted warehouse. The client has brought a DJ for the drinks reception, and the DJ has brought a mixer with RCA outputs. The house console is thirty metres away at the back of the room.

The runner who met the DJ found a pair of RCA to jack leads and two long jack cables, plugged them into a stage box, and told you the DJ is in. On the console, channels 23 and 24 show almost nothing. Someone has already pushed the input gain up to the top, and now you can hear the DJ — along with a steady hum and the buzz of the dimmers.

You can name every problem from the chapter you have just read. The DJ mixer's outputs are consumer level, unbalanced. They have been run as unbalanced signals into mic inputs, which are the wrong level, and turned up at the preamp, which brought the noise up with the music. The thirty-metre run picked up interference along its length, and nothing at the far end could reject it because the line was never balanced.

The fix takes three minutes. A stereo DI box goes on the DJ's table. The RCA leads go into it, a short unbalanced run, and two ordinary mic cables go from its balanced outputs to the stage box. The input gain comes back down to a sensible setting, because a DI's output is at the level the input expects. The hum is gone and the level is right.

Nothing was broken. Two signals were simply the wrong kind for the stage they were plugged into.

How to do it

1. Name the output — what kind of signal it is, at what level, balanced or unbalanced.
2. Name the input — what kind of signal it expects.
3. If the levels differ, put the right device between them — a DI box, a pad, a level converter — rather than fixing it with gain.
4. If an unbalanced signal has to run any distance, balance it close to the source.
5. For video, confirm the format the source sends and the formats the next device accepts.
6. For digital audio, confirm the sample rate and which device provides the clock.
7. For control, confirm the protocol and settings match at both ends.
8. Never connect a speaker output to anything but a loudspeaker.

What goes wrong

Practice it

Answer before checking.

Tracing a Signal

The practical skill that flows from the model: follow any signal, stage by stage.

Naming every stage

Tracing a signal means following it from source to destination, naming every stage it passes through. Take the simplest real system — a microphone heard through a speaker — and name each stage: microphone, mic cable, console input, console processing, console output, cable to amplifier, amplifier, speaker cable, loudspeaker. Even this simplest system has many stages, each a point where the signal exists and could be helped or stopped. Being able to trace a chain stage by stage — to say exactly what the signal passes through — is the practical skill that the source-destination model gives you, and it is the foundation of understanding and fixing systems.

Tracing builds from simple to complex. Once you can trace one chain, you add branches: a second source, a recording feed, a monitor send — each just another small chain joining the system. A complex system is not different in kind from a simple one; it is many simple chains overlapping, which you trace one at a time. This means there is no AV system too complex to understand — you trace its flows one by one, and the whole becomes clear. Tracing is how the model becomes a usable skill.

Upstream and downstream

The core habit of signal-flow thinking is, for any point in a system, knowing what is upstream (what feeds it) and what is downstream (what it feeds). Point at any device and you should be able to say what comes before it and what comes after. This upstream-downstream awareness is what lets you reason about a system: to understand how a change at one point affects everything after it, to know where a signal comes from and where it goes, and — crucially — to find faults by knowing where to look. It is the working form of signal-flow understanding.

This habit pays off constantly. When building a system, you connect outputs to inputs correctly because you think in upstream and downstream. When operating, you understand how your actions flow through the system. When troubleshooting, you trace upstream from a dead destination or downstream from a working source to find where the signal stops. Always knowing what is upstream and downstream of where you are is the reflex that signal-flow mastery gives you, and it makes you capable across every part of AV.

Tracing on paper, confirming at the connector

On a small system you trace by following cables with your hands. On anything bigger, nobody does that, because the cables run through floor boxes, trays, looms and patch panels where following them is slow and often impossible. Professionals trace on paper first and confirm at the connector.

Three documents do most of the work. An input list, usually for audio, gives every source a number and a name: channel 1 kick drum, channel 14 lectern microphone, channel 23 playback left. A patch sheet says where each of those enters and leaves the system: stage box A input 14, console channel 14, output to matrix 3. A cable schedule gives every cable a number and records both ends.

Cable numbers are the link between the paper and the room. A properly labelled cable carries the same number at both ends, and that number appears on the schedule. When you find cable 214 in a floor box, the schedule tells you where its other end is without anybody walking the run.

So a trace on a documented system reads the path on paper — source, stage box input, snake, console channel, bus, output, amplifier, loudspeaker — and then goes to the connectors at the points in question to prove what the paper says. When the paper and the room disagree, the room is right, and the paper gets corrected before you leave.

Patch bays and normalling

A patch bay brings the inputs and outputs of many devices to one panel so they can be connected with short patch cables. Most are arranged in pairs of jacks, one above the other, with an output on one row and the input it usually feeds on the row below.

The confusing part is normalling. A normalled pair is connected inside the bay even with no cable plugged in, so the signal flows from the output to the input without any visible connection. That is useful, because the usual connections work without a single patch cable, and it is also exactly why normalled bays are hard to trace: the signal path you need to see is inside the panel.

There are three common arrangements. A full normal connects the pair, and plugging a cable into either jack breaks the connection. A half normal connects the pair, and plugging into the input jack breaks it, but plugging into the output jack takes a copy of the signal without breaking the normal — which lets somebody listen to a signal without interrupting it. A non-normalled pair is not connected at all until a cable is patched.

Which row is which, and whether a bay is full or half normalled, varies between bays and is often set by switches or by turning a card round inside. It should be written on the bay's label. When a signal disappears as soon as somebody plugs in a patch cable to listen, the pair was full normalled, not half normalled.

Inserts, sends and returns

Some signals leave a console partway through its processing, go somewhere else, and come back. Every one of those is a small chain inside the bigger one, and every one is a place where the signal can leave and fail to return.

An insert breaks the signal path of a single channel or bus at a set point, sends it out to an external processor such as a compressor, and brings it back in to continue. If the processor is off, unplugged or bypassed wrongly, the channel goes silent — and on an analog console an insert jack with the wrong cable in it can break the channel with nothing connected to it at all. On a digital console the same idea exists as an insert point in the software.

An aux send takes a copy of one or more channels, at a level set per channel, and sends it to a separate output. Aux sends feed monitor mixes, in-ear mixes, effects processors, recording feeds and the mix a remote guest hears. The original channel carries on unaffected.

A return brings a signal back into the console: the output of a reverb, the audio from a video call, a feed from another desk. Returns have their own gain and their own place on the desk, and forgetting a return is one of the most common reasons an effect or a remote guest cannot be heard.

Each of these has a question attached, and the question is whether the send is pre-fader or post-fader. A pre-fader send is taken before the channel fader, so the monitor mix does not change when the front of house engineer moves a fader. A post-fader send follows the fader, so an effect fades with its source. Tracing a send without knowing which it is will find a fault where there is none.

Splitting one source to several destinations

A band's microphones are wanted by the front of house engineer, the monitor engineer, the broadcast truck and a recording, all at once. A microphone cannot be plugged into four places, so it is split.

A direct split, sometimes called a hard split, simply wires one input to several outputs. It is cheap and has no electronics, and it shares everything: every console connected to it can see the microphone's phantom power, and all of them share its ground, which invites hum between systems.

A transformer isolated split gives one output a direct connection and the others a connection through a transformer. The isolated outputs carry the signal without a direct electrical connection, so grounds are separated and phantom power sent from one console does not reach the others. This is the traditional way to split a stage between front of house, monitors and a broadcast truck.

An active split uses powered electronics to buffer each output.

Digital systems changed the question. Many consoles now share one stage box on a network, and there is only one microphone preamp per input. One console owns the preamp gain, and if two engineers each turn it to suit themselves, each changes the other's level. The answer is gain compensation, sometimes called gain tracking: one console sets the preamp, and the others see a level that stays constant while they use a digital trim of their own. Knowing who owns the preamp is now part of the patch.

Phantom power and polarity travel with the signal

Two things ride along a microphone cable that are not the sound, and each can cause trouble a long way from where it was set.

Phantom power is a 48 volt supply sent from the console or stage box, back up the microphone cable on the same two signal conductors, to power condenser microphones and active DI boxes. It flows against the signal. It is switched on at the input, which may be on a console at the far end of the room, and it arrives at the connector in your hand. Dynamic microphones ignore it. Some older ribbon microphones and some unbalanced devices can be damaged by it. Plugging and unplugging a cable with phantom on makes a loud pop through the system. So connections are made with phantom off and it is switched on afterwards, and it is switched off before anything is unplugged.

Polarity is whether the signal's positive swings stay positive. A cable with pins 2 and 3 swapped, a device wired to a different convention, or a polarity button pressed on a channel inverts the signal. On its own, one inverted source sounds the same. Combined with another microphone on the same source, or with a loudspeaker next to a correctly wired one, the two partly cancel, and the sound goes thin, loses its low end or disappears in places. Polarity faults are silent in the patch and only audible in the room, and they are traced exactly as any other signal is: stage by stage, asking where it was inverted.

Paperwork a trace uses

Patch bay normalling

Splitting a microphone

On the job

A theatre show with a band in the pit. Front of house and monitors each have their own console, fed from a transformer isolated split on stage. The sound check was fine. Twenty minutes before the house opens, the monitor engineer says the backing vocalist's microphone has gone completely dead in her wedge.

You start at the paper. The input list says the backing vocal is channel 19. On the front of house console, channel 19 is working, so the microphone, its cable, the stage box input and the split's direct side are all proven good. The fault is somewhere after the split, on the monitor side only.

The split's isolated output for input 19 goes to the monitor stage rack. On the monitor console, channel 19's meter shows nothing. So the signal is not arriving at the monitor console. Between the split and that meter are only two things: the split's isolated output and the multicore to the monitor rack.

At the split you find that somebody patched a spare microphone into the monitor side of input 19 to test it during the break, and pulled the tail of the multicore half out when they removed it. The connector is seated but not latched. You push it home and it clicks. The meter jumps.

The whole trace took three steps, and two of them were on paper: which channel, and which side of the split was proven good by the other console.

How to do it

1. Find the source on the input list and note its number.
2. Read its whole path on the patch sheet — every input, bus, send and output it passes through.
3. Note every split, insert and send on the path, and whether each send is pre- or post-fader.
4. Mark what is proven good by other destinations that are working from the same source.
5. Go to the first point on the path that is not proven, and confirm the signal there with a meter, headphones or a monitor.
6. Move downstream one stage at a time until the signal is missing.
7. Correct the paperwork if the room and the paper disagree.

What goes wrong

Practice it

Answer before checking.

Level Through the Chain

A signal can reach every destination it should and still be wrong, because it arrived too quiet, too loud, noisy or distorted. Where a system's level is set matters as much as whether the signal gets there, and it is the commonest fault in live audio that nobody calls a fault.

This chapter is gain structure: what each stage in a chain does to level, why it is set at the start and not the end, where distortion and noise are built into a system, and how to read the meters that show you a level you cannot hear. It is written for audio, because that is where it bites hardest, and the same idea applies to video levels and to every signal that passes through a chain of stages.

Gain structure — setting level at the right stage

Every stage in a chain can make a signal louder or quieter. A preamp adds gain, a channel fader sets a level, a bus fader, a matrix output, a processor's input and output, and finally an amplifier all do too. There are many ways to get the right loudness in the room, and only a few of them sound good.

Gain structure is the practice of setting each stage so the signal passes through all of them at a healthy level: strong enough to stay well above the noise, and far enough below the point of distortion to handle the loudest moments. The rule underneath it is to set level as early in the chain as possible and to leave the later stages near their normal operating point.

On a console, that means the preamp gain is set so the channel is strong at a normal performance level, and the faders then sit near their marked unity point, where they neither add nor remove level. Unity gain is the setting at which a stage passes a signal through at the same level it received it. A system where every stage after the preamp sits near unity is usually a system with good gain structure.

The reason the start matters is noise. Every stage adds a small amount of its own noise. A signal that is too quiet at the preamp and then boosted by a fader, a bus and a processor carries the preamp's noise with it through every boost, and adds more at each stage. A signal that is strong from the start and passed through at unity rides above all of that noise.

The reason the end matters is distortion. An amplifier driven by a processor that has been turned down to compensate for a console that is too hot is running with no margin at all somewhere upstream. When the loudest moment arrives, the stage with the least margin clips, and that is rarely the one whose meter somebody is watching.

Headroom, noise floor and clipping

Every stage has a range it can work in. At the bottom is the noise floor, the constant hiss and hum the stage produces with no signal at all. At the top is its maximum level, above which the stage cannot produce any more and the tops of the waveform are cut off flat. That is clipping, and it sounds like harsh, crackling distortion that no later stage can remove.

The normal operating level sits between the two. The space from the normal level up to clipping is headroom, and it exists to absorb the peaks: a singer's shout, a snare hit, a sudden laugh in a quiet room. A system with little headroom sounds fine in sound check and distorts on the first loud moment of the show.

The space from the normal level down to the noise floor is the signal-to-noise ratio. A signal set low has plenty of headroom and too little clearance above the noise, and the hiss becomes audible when anything is turned up.

Gain structure is keeping every stage balanced between those two limits. The trap is that the limits are different at every stage. A console might have a great deal of headroom above its normal level, a processor after it rather less, and a small powered speaker less again. The stage with the least headroom clips first, however carefully everything upstream was set, and that stage sets the ceiling for the whole system.

In digital equipment the ceiling is exact. 0 dBFS is the top and there is nothing above it; an analog stage may soften into distortion, a digital one cuts off instantly. This is why digital levels are set to leave a clear margin below full scale, and why many broadcast and live systems align a reference level well below it — commonly −18 or −20 dBFS for the analog reference level.

Pads, input gain and trim

The first control a signal meets is the most important, and the one most often misunderstood.

Input gain, often simply called gain, sets how much the preamp amplifies the incoming signal. For a quiet microphone it is set high; for a loud kick drum microphone low; for a line level source very low. It is set at sound check with the source at performance level, not whispering into the microphone.

A pad is a fixed reduction, commonly 20 dB, switched in before the preamp. It exists for signals so hot that even the lowest gain setting would overload the input: a line level source into a mic input, a condenser microphone inches from a kick drum. A pad is the only control that can prevent that overload, because the distortion happens before any gain control can act.

Trim is a gentler adjustment, usually for line level inputs or, on digital consoles, a digital level control after the preamp. On a shared stage box it is how a second console adjusts its level without touching the preamp another engineer owns.

The order of thought is always the same: is the signal overloading the input? Pad it. Is it at a healthy level on the channel meter? Set the gain. Only then touch anything after it.

Reading meters at every stage

A meter shows a level you cannot hear, and every stage that matters has one. Using them is how you find the stage that is too hot or too quiet without listening to each one in turn.

The input meter on a console channel shows the signal after the preamp. It is the most important meter in an audio system, because it shows whether gain was set correctly. Bus and output meters show what the mix is sending. Processors, wireless receivers, amplifiers and powered loudspeakers usually have meters or at least signal and clip lights, and they are the ones people forget to look at.

Meters do not all mean the same thing. A peak meter responds instantly and shows the highest point of the signal, which is what matters for clipping. An averaging meter, often called a VU meter on analog equipment, shows something closer to perceived loudness and reads much lower than the peaks. Digital meters are usually marked in dBFS with 0 at the top; analog meters are marked relative to their own reference level. So a signal at "0" on one meter and at "−18" on another may be exactly the same level.

A clip light that flashes is the most useful light in a rack. Whichever stage lights one first is the stage with the least headroom, and gain upstream of it is the thing to reduce. When a system distorts, walk the chain from the source, reading each meter, and look for the first one that is too high. That is the same last-good, first-bad logic as any trace, applied to level.

Video has levels too

Level is not only an audio idea. A video signal has a range as well: black at the bottom and a maximum white at the top. A picture pushed above the maximum loses detail in the brightest areas in exactly the way audio clips, and a picture held too low looks murky and shows noise when somebody brightens it later.

On professional video equipment the level is watched on a waveform monitor, which shows brightness from black to peak white across the picture, and each stage — camera, converter, switcher, processor, LED processor — can change it. A washed-out LED wall and a crushed, dark projection image are often level faults somewhere upstream, traced the same way as an audio one: find the first stage where the picture goes wrong.

One video level fault is specific to computers and displays. Computer graphics use the full range of numbers for black to white, while broadcast video reserves a small margin at each end. When one device sends full range and the next expects the smaller video range, blacks turn grey and whites dull, or blacks crush and highlights clip. The cable is perfect. The fault is a range setting, and it lives in a menu at one end of the link.

The words of level

Common reference alignments

Where analog and digital meets. Systems choose one alignment and keep to it.

Order of setting level

• Pad the input if the signal overloads it.
• Set preamp gain for a strong signal at performance level.
• Leave faders and outputs near unity.
• Set processors to pass signal at their normal level.
• Set amplifier or powered speaker input to match the system, as designed.
• Adjust loudness in the mix, not by rescuing earlier stages later.

On the job

A corporate awards dinner. The system was set up by a technician who has now gone to another job, and the client's producer has come to you: "the presenter sounds fuzzy when he gets excited".

You check the console first. The lectern microphone's input meter peaks healthily, well short of clip. The channel fader is up by several decibels, the main bus fader is at unity, and the matrix output feeding the room's loudspeaker processor is at its maximum. So the console is sending a hot signal to the processor.

At the processor rack, the input meter for the main feed is sitting near the top of its scale with the presenter speaking normally, and the clip light flickers every time he raises his voice. To stop the room from being too loud, the previous technician had turned the processor's output down a long way. Every stage after the console had been adjusted to cover the stage before it, and the processor's input — the stage with the least headroom — clipped first.

You bring the matrix output down to unity, which drops the level arriving at the processor by several decibels, and raise the processor output by the same amount so the room stays as loud as it was. With the presenter shouting into the microphone the processor's clip light no longer comes on. He sounds clean for the rest of the night, and the loudness in the room never changed.

How to do it

1. Start with every fader and output at unity and the amplifiers or powered speakers turned down.
2. Ask the source to perform at show level — a real voice, a real instrument.
3. Pad the input if it overloads, then set preamp gain so the input meter is strong with clear headroom.
4. Check every meter after the console — processor inputs, amplifier inputs — at that level.
5. Correct any stage that is hot or quiet at its own input, rather than compensating further down.
6. Bring amplifiers or powered speakers up to the loudness the room needs.
7. Test with the loudest moment the show will have, and watch every clip light on the chain.

What goes wrong

Practice it

Answer before checking.

Conversion, Extension and Handshakes

Between the source and the destination, a modern system is full of small boxes that do not route or mix anything. They convert a signal into another form, carry it further than its cable can, or negotiate what it is allowed to be. They are some of the least visible stages in a system and some of the most frequent causes of a black screen with nothing obviously wrong.

This chapter covers what each kind of box does to the signal, the delay each one adds, and the two handshakes — EDID and HDCP — that make a correctly wired video chain refuse to show a picture.

Conversion — ADC, DAC, scaling and frame sync

A converter changes a signal from one form into another, and every one of them is a stage with its own settings, its own power supply and its own ways to fail.

An analog-to-digital converter, ADC, turns a voltage into numbers; a digital-to-analog converter, DAC, turns numbers back into a voltage. Every digital console input has one and every digital output ends in one, and they are also sold as separate boxes. They have a sample rate and a clock, and they have a maximum level, which is where 0 dBFS lives.

A scaler changes a video signal's resolution, so a 1280 by 720 laptop can fill a 1920 by 1080 display or a pixel-exact LED wall. A cross-converter changes format more broadly — resolution, frame rate, interlaced to progressive. A format converter changes the connection itself: HDMI to SDI, SDI to HDMI, analog to digital. Many single boxes do several of these at once.

A frame synchroniser, or frame sync, takes a video source that is not locked to the system's reference — a laptop, a camera from another truck, a feed from the internet — and holds and re-times its frames so they line up with everything else. Without one, cutting to that source glitches or rolls on a switcher that expects everything in time.

Conversion should happen at the edge of the system. Sources arrive in all sorts of formats; the system runs in one show format; each source is converted once, close to where it enters. A signal converted several times as it passes through — upscaled here, frame-rate converted there, down-converted again for a monitor — loses quality at each stage and gains delay at each stage.

Embedding and de-embedding audio

SDI and HDMI both carry audio channels inside the video signal. Putting audio into a video signal is embedding, and taking it back out is de-embedding. Both happen constantly and invisibly.

A camera embeds its microphone audio in its SDI output. A laptop embeds its sound in HDMI. A switcher may pass embedded audio from whichever source is on program. A stream encoder takes its sound from the audio embedded in the program feed. An LED processor or projector receives the audio and ignores it.

The fault this creates is the vanishing sound. A laptop's playback audio is travelling inside its HDMI signal; it passes through a scaler that does not pass audio; it arrives at the switcher with no sound in it. Or a stream has pictures and no audio because the console's program mix was never embedded into the feed going to the encoder, and the embedded audio the encoder is carrying is the silence from a camera.

So whenever a sound travels with a picture, trace both. Ask at each box on the video path whether audio is passed, stripped or replaced, and write down where the audio is taken out for the console and where the console's mix is put back in for anything that needs it.

Extension — twisted pair, fiber and distance

Every signal has a distance beyond which it stops working. Extension equipment carries it further.

Twisted pair extenders, HDBaseT among them, carry HDMI, audio, control and sometimes network over a category cable — up to around a hundred metres between a transmitter and a receiver. They are the standard way to get a laptop at a lectern to a projector or a display across a room. They care about the cable: a solid-core cable of the right category, terminated properly, is required, and a run through a patch panel, a coupler or a wall plate can use up the distance.

Fiber carries signals far further than copper — hundreds of metres to many kilometres — and it is immune to electrical interference and ground loops, because there is no electrical connection along it. SDI, networks, audio and camera signals all travel on fiber when distance, interference or isolation matter. It is also delicate: a dirty connector end or a sharp bend loses signal, and one speck of dust on a fiber end can stop a link completely. Fiber ends are inspected and cleaned, and dust caps are kept on.

Extenders are stages. They need power, often at both ends, and they are often small boxes hidden in a floor box or behind a display. A receiver with no power is a stage where the signal stops, and it is exactly the kind of stage nobody remembered was there. They also usually handle EDID and HDCP themselves, which makes them part of the handshake the next sections describe.

EDID — how a source decides what to send

When a laptop is plugged into a display, it asks the display what it can show, and the display replies with a small block of data called EDID, extended display identification data. EDID lists the resolutions, frame rates and audio formats the display supports and which one it prefers. The laptop reads it and chooses what to send.

On a direct connection this is invisible and works. In a system, there is not one display at the end of the cable. There may be an extender, a switcher, a distribution amplifier and a scaler, and each of them either passes on the EDID of what is downstream or presents its own. Whatever the source reads is what the source believes it is connected to.

This causes three of the most common video faults. A laptop outputs a resolution the real display cannot show, because a switcher passed along the EDID of a different display. A laptop outputs a low, safe resolution because a box in the chain presented a basic default EDID. A laptop picture flickers or changes resolution each time somebody switches the switcher, because the EDID changed and the laptop renegotiated.

The fix is EDID management. Switchers, distribution amplifiers and extenders let you set the EDID each input presents — usually to the show format, or to a copy of the main display's EDID — so every source sees one consistent, correct answer no matter what is switched downstream. Setting it is part of building the system, and checking it is part of tracing a video fault that the cable cannot explain.

HDCP — copy protection as a handshake

HDCP, high-bandwidth digital content protection, is how protected content — a streaming service, a film, some media players and many laptops — makes sure it is only shown on equipment that is licensed to show it. Before the source sends a picture, it checks that the device it is connected to is HDCP compliant, and that every compliant device downstream is too.

If every device in the chain passes the check, the picture appears and nobody notices. If one device in the chain is not compliant, or supports only an older version, the source refuses, and the result is a black screen, a snowy image or a message such as "HDCP error" on the display. The cabling is perfect.

The versions matter. Protected UHD content usually requires HDCP 2.2 or later, and a chain where one extender, switcher or display only supports an earlier version will show HD content and refuse UHD content from the same source.

HDCP also explains why some things are impossible by design. Many capture devices and recorders will not accept HDCP-protected signals, and SDI does not carry HDCP at all, so a compliant converter will not turn protected HDMI into SDI. When a client's media player works on the television at home and goes black on the stage, this is usually why.

Many switchers let you turn off HDCP on an input, which tells sources the input is not compliant. Sources that do not need protection then send unprotected video, and the chain can include recorders and SDI conversion. Sources that insist on protection will refuse that input entirely, and the only answer is a different source for that content.

Latency and lip sync

Every stage that stores and processes a signal delays it. A digital console delays audio by a few milliseconds. A scaler, a frame synchroniser or a video processor may hold a frame or more — at 50 frames per second, each frame is 20 milliseconds, at 25 it is 40. A projector or LED processor adds more. A wireless video link, a stream encoder and a video call add a great deal.

Pictures usually pass through more processing than sound, so a room's video tends to arrive later than its audio. A presenter on a large screen whose lips move after the words are heard looks wrong even to people who could not name the problem. The effect is especially noticeable when sound arrives before the picture, because in nature light always arrives first.

The usual fix is to delay the audio to match the picture, at the console or the loudspeaker processor, by the delay of the video chain. It is measured, not guessed, often with a test clip that flashes and beeps at the same instant, and it changes whenever a box is added to or removed from the video chain.

Latency also matters for performers. A presenter watching themselves on a confidence monitor, a singer hearing themselves through a digital in-ear system, and a remote guest on a video call all notice delay, and the acceptable amount is much smaller for a performer's own voice in their ears than for an audience watching a screen. Knowing the delay each stage adds is part of knowing the system.

The boxes between source and destination

Delay you can expect

Rough figures to reason with. Measure the real chain.

Signs of an EDID fault

• The wrong resolution arrives at a display that could show the right one.
• A source falls back to a low default resolution.
• A picture flickers or resizes when something downstream is switched.

Signs of an HDCP fault

• Black or snowy picture from one source only, with a good cable.
• Protected content fails while the desktop or slides work.
• UHD content fails where HD content from the same source works.
• A recorder or SDI converter shows nothing from an HDMI source.

On the job

A product launch in a hotel. The client's video team brought a media player with the launch film on it, and it works perfectly on their monitor in the green room. On stage, through the house system, the LED wall shows the player's menu and then goes black the moment the film starts.

The laptop showing slides on the same input works. The cable has been swapped. The client is starting to look at you.

Menu visible, film black. That is the pattern of copy protection: the menu is not protected and the content is. You look at the chain. Media player, HDMI to an extender, to a switcher, from the switcher's SDI output to the LED processor, and from another output to a recorder that is capturing the show for the client.

SDI cannot carry HDCP. The switcher, correctly, will not send protected content out of its SDI outputs, so the film goes black on the only path that reaches the wall.

Nothing in the house system can legally change that, and saying so clearly is part of the job. You ask the video team whether the film exists as an unprotected file. It does, on a USB stick, because they made it. It goes onto the playback laptop, which sends unprotected video, and the film plays on the wall and into the recording. The media player goes back in its case.

How to do it

1. Find out the source's output format and whether it will send protected content.
2. Set the source, or the input it arrives at, to the show format.
3. Set the EDID that input presents, so the source chooses the right format.
4. Check whether audio is embedded, and where it is to be de-embedded or replaced.
5. Confirm every box on the path is powered, including extenders at both ends.
6. Check the whole path accepts HDCP if protected content must pass, or disable HDCP on the input if it must reach recorders or SDI.
7. Test with the real content, not just a desktop.
8. Measure the added delay if the source carries a presenter's lips, and adjust audio delay.

What goes wrong

Practice it

Answer before checking.

System Architecture

Zoom out from a single chain to the whole system: inputs, a core, and outputs.

Inputs, core, and outputs

Beyond a single chain, whole AV systems have an architecture, and a powerful way to understand any system is as inputs, a core, and outputs. The inputs are all the sources coming into the system (the microphones, cameras, laptops, playback). The core is the processing and routing heart (the consoles, switchers, processors, matrixes that handle and direct everything). The outputs are all the destinations the system feeds (the speakers, displays, recorders, streams). Inputs flow into the core, the core processes and routes, and the results flow out to the outputs. This architecture — inputs, core, outputs — describes the shape of essentially any AV system, large or small.

Seeing a system this way makes even a large, complex installation comprehensible: however many sources and destinations and however elaborate the core, the system is still inputs feeding a core that routes to outputs. It is the source-processing-destination model at the scale of a whole system. When you walk into a complex AV system and see it as inputs, core, and outputs, you have a framework to understand it, rather than being overwhelmed by the quantity of gear. This architectural view is how professionals comprehend whole systems.

Reading a system's architecture

Understanding architecture lets you read how a whole system is connected and behaves. The core (the routing heart) is where you understand how any input can reach any output — a switcher or matrix in the core lets sources be routed to destinations flexibly. Knowing the architecture tells you what the system can do (what sources can go to what destinations), how it is organised, and where to look for any part of the flow. This is the same understanding captured in a signal-flow diagram (drawn and read in the chapter on drawing and reading a system): the architecture is what the diagram shows, and reading it is reading the system.

This architectural thinking scales the signal-flow skill from a single chain to entire systems and installations. A large venue's AV, a broadcast facility, a complex show — all are inputs, a core, and outputs, with signals flowing through. Grasping a system's architecture lets you understand, operate, design, and troubleshoot it as a whole, not just chain by chain. Combined with tracing individual flows, architectural understanding is the complete signal-flow competence: you see both the whole system's shape and every signal's path through it.

One to many, many to one, many to many

The core of a system is the box, or set of boxes, that decides which inputs reach which outputs. It comes in three basic shapes, and knowing which one a system has tells you what it can and cannot do.

A distribution amplifier, a DA, takes one input and sends identical copies to several outputs: one-to-many. It is how one program feed reaches six confidence monitors, or one clock reaches ten devices. It makes no decisions.

A switcher takes several inputs and selects one to send to its output: many-to-one. A presentation switcher chooses which laptop is on the screen. A production switcher adds transitions, keys and several outputs, but at its heart it is the same idea.

A matrix, also called a router, connects any input to any output, independently: many-to-many. Output one can show input three while output two shows input seven and output three also shows input three. Broadcast routers, meeting room matrices and audio console buses all behave this way.

A mixer is a fourth shape that only makes sense for some signals: many inputs combined into one output, in proportions. Audio consoles mix; a video switcher can mix two pictures in a transition; lighting consoles combine the output of many cues into one set of levels. Video and control signals are usually routed rather than mixed.

When you are handed a system, find its core and name its shape. It tells you immediately whether a given source can reach a given destination at all, or only one at a time, and where the decision is made.

Centralised and distributed, point-to-point and routed

Where the core physically sits is a separate question from what shape it is, and it decides where you walk when something goes wrong.

A centralised system brings every signal back to one place — an equipment room, a rack at front of house, a broadcast truck — and makes every decision there. It is easy to understand and easy to document, and a failure in that one place affects everything.

A distributed system places processing close to the sources and destinations: a stage box on stage, a processor beside the loudspeakers, a transmitter at every lectern and a receiver at every display, all connected by a network. It needs far less cable and each part is simpler, and the system's logic is spread across many boxes that may all look alike.

Point-to-point wiring connects each source directly to its destination with its own cable, like a microphone into a small mixer. It is simple, visible and inflexible. Routed systems connect every source to the core and every destination to the core, so any change is made at the core. Networked systems are routed systems where the core is software and the cables no longer describe the routes, which is the whole of the next chapter.

Most real systems mix all of these. A conference might have a centralised audio console, distributed stage boxes on a network, a centralised video router, and a point-to-point feed to a press box. Trace each part in the shape it actually has.

Mixes and feeds out of the core

A show does not send one version of itself. It sends many, each built for a different listener or viewer, and each is a separate output from the core with its own path.

The main mix goes to the room. Monitor and in-ear mixes go to performers, each different. A record feed goes to a recorder, often without the room's delay and processing. A stream feed goes to an encoder, usually a different mix, because what sounds right in a large room sounds wrong on headphones. A press feed goes to a box of outputs where journalists plug in. A broadcast truck may take individual microphones and make its own mix. Video has the same idea: program to the screens, a clean feed without graphics to a recording, a different picture to confidence monitors, a multiview to the director.

One feed has a name of its own because it is pure signal flow. A mix-minus is a mix of everything except one source, sent back to that source. A remote guest on a video call must hear the presenter and the audience, and must not hear their own voice coming back delayed from the room, or they will hear an echo and struggle to speak. So the guest's return is the whole show minus the guest. On a console it is usually built with an aux send or a matrix, with the guest's own channel left out. Every remote contributor needs one, and each is different.

When a feed fails, the question is always which output it is, which mix builds it, and whether the source in question is in that mix.

Redundancy — main and backup paths

Shows that cannot stop are built with a second path for anything whose failure would stop them. Redundancy is signal flow planned twice.

The common forms are simple. Two playback computers run the same content in sync, main and backup, both feeding a switcher, so an operator can cut to the backup in one button press. Two network switches carry the same audio on primary and secondary networks, so a failed switch or cable loses nothing. Two encoders send the same stream. Two power feeds come from two sources, and uninterruptible power supplies keep processors alive through a glitch.

Redundancy only works if the backup path is traced as carefully as the main one. A backup playback machine whose output was patched to the wrong input, whose content is a version behind, or whose audio goes nowhere is not a backup. It is a second failure waiting behind the first.

So redundant paths are tested by actually changing over, before the show, with real content, and watching every destination. The changeover procedure — who calls it, who presses what, and what the operator watches to confirm it worked — is written down as part of the system.

The control layer as its own architecture

A room with a touch panel has a second system laid over the first. The signals run from sources to destinations through the core; the commands run from the panel to a control processor and out to every device the panel can operate. That control layer has its own architecture, its own wiring and its own faults.

The control path is the route commands take. It might be IP over the network to a matrix and a camera, serial to a projector, IR to a cable box, relay to a screen motor, and network to a lighting controller, all from one processor. When a button does nothing, the question is whether the command left the panel, reached the processor, left the processor on the right port, and arrived at a device that was listening.

Two things make this confusing. First, the control path is almost never on the signal drawing, so it has to be traced from the control system's own documentation or by looking at the processor's ports. Second, a device may be controlled from more than one place — a projector's own remote, a front panel, the touch panel — and a device changed by hand no longer matches what the control system thinks it has done.

So whenever a system is controlled, trace two architectures: the signal architecture and the control architecture, and check that the device a command reached is the device that carries the signal.

Shapes of a core

Feeds a show sends

On the job

A hybrid town hall for a large company. The CEO is on stage; a regional director is joining from another country on a video call, shown on the screen and heard in the room. In rehearsal the regional director says she can hear herself, a second late, every time she speaks, and it keeps making her stop mid-sentence.

It is an echo, and it is a signal flow question. Her voice arrives from the call, into a console return, into the main mix, out of the room loudspeakers and — the fault — back to her. The console's feed to the video call computer was built from the main mix. The main mix contains her channel. So she hears herself, after the call's delay.

You build a mix-minus. On a spare aux send you add every microphone, the playback and the audience microphones, and leave her channel out. That aux becomes the feed to the call computer. You check it in headphones: the CEO, the audience, the video playback, and no regional director.

She tries again and speaks through without stopping. You write it on the patch sheet as its own output, because the next technician will look for a feed called main mix going to the call and find something called mix-minus instead, and it needs to be clear it is there on purpose.

How to do it

The mix-minus fixed the feed. The other piece of feed work before doors is proving every backup path, by changing over to it.

1. Agree who calls the changeover and who presses what.
2. Confirm the backup source is running the same content at the same point as the main.
3. Confirm the backup path reaches every destination the main path does — screens, record, stream, confidence.
4. Cut to the backup with real content playing.
5. Watch and listen at every destination, including audio, not only the main screen.
6. Cut back to the main and confirm again.
7. Write down the changeover steps and put them where the operator can see them.

What goes wrong

Practice it

Answer before checking.

Signals on a Network

On a network, the cable no longer tells you where a signal goes. The same cable into a network switch might carry sixty microphones, the stream, the lighting and the control system, and which of them reach which device is decided by settings in software. Tracing moves from following cables to reading routes.

The model does not change. There is still a source, processing and a destination, and there is still an upstream and a downstream. This chapter is how to see them when the network hides them: the physical and logical layers, how audio networks describe routes as subscriptions, why clocking and latency matter, and how video and lighting use the same idea. Designing and configuring the network itself is its own subject; this is following a signal across one.

Physical network, logical routing

A networked system has two layers, and a trace has to look at both.

The physical layer is the cables, the network switches and the devices plugged into them. It answers the question of whether a device can reach the network at all. A broken cable, a switch with no power or a port that is not connected is a physical fault, and it is found much like any cable fault: link lights, labels, a cable tester.

The logical layer is what the devices have been told to send to each other. A console's stage box and its surface might both be plugged into the same switch, and nothing flows between them until the software says it should. The route exists only as a setting.

So a network trace asks two questions in order. Is every device on the path physically connected, powered and seen on the network? Then, is the route set, and is it working? A device can have perfect physical connections and no logical route, and a route can exist in software to a device that is unplugged.

The drawing reflects this. A networked system is drawn twice: a network drawing of which device plugs into which switch port, and a signal flow drawing of which channels go where, as if the network were not there.

Devices, channels and subscriptions

Networked audio systems such as Dante describe routes in a particular way, and learning it once makes most of them readable.

Every device on the network advertises itself by name, and advertises its channels. A stage box transmits sixty-four input channels and receives sixteen output channels. A console receives sixty-four channels and transmits thirty-two. A recorder receives sixty-four.

A route is made by a receiving device subscribing to a transmitting device's channel. The console's channel 1 subscribes to the stage box's channel 1. The recorder's channel 1 also subscribes to the stage box's channel 1. The routing is set on the receiver's side, and one transmitter channel can be received by many devices at once. Routing software shows this as a grid, with transmitters along one side and receivers along the other, and a tick where a subscription exists.

Because subscriptions are made by name, renaming a device breaks every route to it until the receivers are updated. And because a subscription is a setting, it can exist to a device that is switched off or has gone, in which case the software shows it as unresolved.

Audio travels between devices in flows. A device can send a limited number of separate flows, and sending the same channels to many receivers can use them up; multicast flows let one flow reach many receivers at once. When a new receiver cannot subscribe to a transmitter that others can hear, this is often why.

Tracing a networked audio signal means reading the grid: from the source's device and channel, to every receiver subscribed to it, and then inside each receiver to where that channel goes next.

Clock and latency on the network

Digital audio devices must agree on time, and on a network they do it by electing one device as the clock leader. Every other device is a follower and adjusts itself to the leader. The election is automatic, and a device can be set as preferred leader, or told to take its clock from an external word clock signal.

When clocking is right, nobody notices. When it is wrong — two leaders, a leader on a device that is about to be switched off, a device that cannot lock — the symptoms are clicks, dropouts and occasional silences that look exactly like a bad cable. The routing software shows the clock status of every device, and a device that is not locked is the first thing to look for when a networked system clicks.

Latency is set per receiving device: how long it waits for audio to arrive across the network before playing it out. A short latency is good for performers and needs a fast, uncongested network; a longer one tolerates more switches and busier links. Settings of around one millisecond are common for audio devices on a well-built local network. A latency set too short for the path the audio takes produces clicks and dropouts on that receiver only.

Both are part of tracing. A signal on a networked system has not been traced until you know it is subscribed, that both ends are locked to the same clock, and that the receiver's latency suits the route.

Redundant networks

Many networked audio devices have two network ports, primary and secondary. Connected to two completely separate networks — separate switches, separate cables — they send and receive every channel on both at once. If a cable or switch on one network fails, the audio continues on the other without a click.

Two separate networks means exactly that. The primary and secondary networks are never connected to each other, and a device's secondary port is never plugged into the primary switch. Doing so does not add redundancy; it can cause problems across the whole network.

A redundant network is traced twice, like any backup path, and tested by unplugging one side during setup and confirming nothing drops.

Video and lighting on networks

The same logical idea now carries pictures and lighting control, with different names for the parts.

NDI is a common way to send video on a production network. Sources appear on the network by name — a camera, a laptop running NDI software, a graphics computer — and a receiver chooses which source to show. There is no grid of subscriptions to edit in advance in the same way; each receiver selects a source, much like tuning a television. NDI video is compressed, and the more heavily compressed forms need more care about delay.

AV over IP is the broader name for systems that send video on networks, from meeting room products that replace HDMI extenders and matrices with transmitters and receivers on a switch, to broadcast facilities built on standards such as SMPTE ST 2110. In a meeting room system, a transmitter at each source and a receiver at each display are the inputs and outputs, and routing is choosing which transmitter a receiver listens to.

Lighting networks carry DMX universes over Ethernet using sACN or Art-Net. The console sends numbered universes onto the network; nodes near the fixtures receive chosen universes and turn them back into DMX on ordinary cables. Some fixtures receive sACN or Art-Net directly. Tracing a lighting network means knowing which universe number each node outputs on which port, and that the console is sending that universe.

In every case, the trace is the same shape: find the source's name on the network, find which receivers are listening to it, confirm the physical connection of each, and follow the signal onward from each receiver.

The two layers of a networked system

Names across networked systems

A networked signal is traced when you know

• Both devices are physically connected and seen on the network.
• The route or subscription exists and is resolved.
• Both devices are locked to the same clock.
• The receiver's latency suits the path.
• Where the signal goes next inside the receiver.

On the job

A conference with a networked audio system. The stage box, front of house console, monitor console and a multitrack recorder all sit on one network. Half an hour before the first session, the recording engineer says channels 33 to 48 on the recorder are showing as unresolved in the routing software. Everything else records.

Everything else working tells you the recorder is on the network, locked, and receiving. The problem is logical and it is specific to those sixteen channels.

The routing grid shows the recorder's channels 33 to 48 subscribed to a device called "StageB". There is no device called StageB on the network. There is a device called "Stage-Box-2" transmitting exactly the sixteen channels of the second stage box.

You ask front of house. During the morning, the engineer renamed the second stage box so its name matched the paperwork. The consoles were updated. The recorder was not.

You re-subscribe the recorder's channels 33 to 48 to Stage-Box-2, and the software shows them resolved. The recording engineer sees signal on all sixteen. Nobody touched a single cable, because no cable was ever at fault.

How to do it

1. Name the source device and channel.
2. Confirm the source device is on the network and locked to the clock.
3. In the routing software, find every receiver subscribed to that channel.
4. Check each subscription is resolved, not waiting for a missing device.
5. Confirm each receiver is locked and its latency suits the path.
6. Follow the channel inside each receiver to its next stage.
7. If a device cannot be seen at all, go to the physical layer — cable, switch port, link light, power.

What goes wrong

Practice it

Answer before checking.

Signal Flow Across Disciplines

One framework, applied to audio, video, lighting, and data — see them all the same way.

Audio, video, and lighting flows

Applying signal flow across disciplines shows its unifying power. An audio system flows from sources (mics, DIs, playback) through a console and processing to destinations (speakers, monitors, recorders) — inputs, core, outputs. A video system flows from sources (cameras, laptops) through a switcher and processing to destinations (displays, LED walls, stream) — the same architecture. A lighting system flows from a console through DMX to fixtures — control flowing from a core to outputs. Each discipline has its own gear and signals, but each is the same source-to-destination flow with an inputs-core-outputs architecture. Recognising this means your signal-flow mastery applies everywhere.

This is why a strong grasp of signal flow makes every discipline easier to learn: you are not learning a new logic each time, just new gear filling the same roles in the same flow. The audio console, the video switcher, and the lighting console are all the routing core of their systems; mics, cameras, and DMX-fed fixtures are sources and outputs. Seeing the common signal-flow structure beneath every discipline is what lets a signal-flow-fluent professional move between and understand them all.

Data, control, and the whole show

Signal flow extends to data and control too. A network carries data from device to device (source to destination across switches — the same flow, as the chapter on signals on a network shows). Control systems flow commands from a controller to devices. Show control flows triggers across systems. Even these less tangible flows follow the model: something originates a signal or command, it travels and is routed, and it arrives somewhere that acts on it. And a whole production is all of these flows — audio, video, lighting, data, control — overlapping in one coordinated system. The grandest show is, at bottom, many signal flows running together.

This complete view — that everything in AV, from a single mic to an entire production, is signals flowing from sources to destinations through processing and routing — is the deep foundation this book delivers. It is why signal flow is taught first: it is the lens through which all of AV becomes understandable. Whatever you go on to specialise in, you are working with signal flow, and the deeper you understand it, the more capable you are across the entire field.

Lighting — control flowing to fixtures

A lighting system is the clearest example of a flow that carries no content at all. The console is the source and the core. What it sends is instructions: for every fixture, a value for every parameter — intensity, colour, position, gobo, focus.

Those instructions travel as DMX universes. A universe is 512 channels. Each fixture is given a starting address in a universe and uses as many channels as it has parameters: a simple dimmer uses one, a moving light may use thirty or more. A fixture set to address 101 in universe 2 reads channels 101 onward and ignores everything else.

On cable, DMX runs as a daisy chain. The signal goes into the first fixture and out of its DMX through connector to the next, and so on, and the last fixture in the chain has a terminator plugged into its output, which prevents the signal reflecting back along the cable and corrupting the data. Because each fixture passes the signal on, a fixture that loses power or has a failing through connector can stop every fixture after it — a classic lighting fault that shows the chain perfectly: everything upstream works, everything downstream does not.

DMX must not be split with a Y cable. Where a run needs to branch, a DMX splitter, usually opto-isolated, gives several separately buffered outputs, and isolates faults on one branch from the others. On larger systems the console sends universes over the network with sACN or Art-Net, and nodes turn them into DMX near the fixtures.

A lighting trace therefore asks: which universe and address is this fixture set to, is the console sending data on that universe, which node or splitter port carries it, and which fixture in the chain is the last one working.

Comms, tally and cue lights

The systems that run the show are signal flows too, and when they fail, they fail in front of the whole crew.

Intercom lets the crew talk to each other. A party-line system puts everybody on a channel on a shared cable, with beltpacks daisy-chained or connected to a base station; everybody on the channel hears everybody else. Two-wire systems carry talk and listen on one pair; four-wire connections separate the two directions, which is how intercom connects to consoles, codecs and matrix systems. A matrix intercom lets each panel talk to and listen to chosen people and groups individually, which makes it a routed system with a core. Wireless intercom adds the radio issues of any wireless link. Intercom is the clearest case of a signal that travels both ways on one connection.

Tally tells a camera operator, and a presenter, which camera is live. The switcher knows which source is on program and on preview; a tally interface or the network turns that into a signal for each camera, which lights a red lamp on program and often a green one on preview. The source of the tally signal is the switcher, and a wrong tally is usually a wrong mapping of switcher input to camera.

Cue lights are the simplest control flow on a show: a lamp at a performer's or a crew member's position, switched from the stage manager's desk, meaning stand by when on and go when off, or whatever the production has agreed. A dead cue light at the moment of a go is a signal flow fault and a show fault at once.

Worked systems you will actually meet

The model becomes a skill when it is applied to whole systems. Here are four a technician meets constantly, each described as inputs, core and outputs.

A meeting room. Inputs: a table connection for laptops, often HDMI or USB-C to a transmitter, ceiling or table microphones, a camera, and the far end of a video call arriving through a room computer or codec. Core: a digital signal processor for audio that mixes the microphones and cancels the echo of the far end's voice from the room, a small switcher or AV over IP system for video, and a control processor behind a touch panel. Outputs: a display, ceiling loudspeakers, and a USB or network connection sending the room's camera, microphones and chosen content to the call. Almost every connection is two-way at some point, and the echo canceller only works if the loudspeaker signal it is given matches what is really coming out of the loudspeakers.

A general session at a conference. Inputs: lectern and wireless microphones, presenter laptops, a playback machine and its backup, cameras for image magnification, and remote presenters. Core: an audio console, a video switcher, and often a matrix router. Outputs: the main and delay loudspeakers, the LED wall or projectors through their processors, confidence monitors, a record feed, a stream feed with its own audio mix, a press feed, and mix-minus returns to each remote presenter.

A band on a stage. Inputs: microphones and DI boxes into stage boxes, a playback rig, and wireless systems. Core: a split feeding front of house and monitor consoles, each mixing independently. Outputs: the main loudspeakers and subwoofers, wedges and in-ear transmitters for each performer, a multitrack recording, and sometimes a broadcast truck taking its own split.

A live stream. Inputs: cameras, graphics, playback, and the audio mix. Core: a switcher building the program picture and an embedder or the switcher itself putting the stream mix inside it. Output: an encoder sending the program to a streaming platform, usually a backup encoder, and a return from the platform — the stream as viewers actually receive it — watched on a monitor, because it is the only proof the stream is working.

Each is the same logic with different gear, which is the whole claim of this chapter.

Across disciplines, the same roles

DMX rules worth writing in the notebook

• 512 channels per universe.
• A fixture uses a block of channels starting at its address.
• Daisy chain with the through connector; terminate the last fixture.
• Never Y-split DMX; use a splitter.
• A fixture that dies can stop every fixture after it in the chain.

On the job

A fashion show in a tent. Twenty moving lights are rigged on a truss above the runway, all on one DMX run from a node at the side of the stage. During the dress rehearsal the lighting designer says the last eight lights have stopped following cues.

The first twelve are working. You go to the chain on paper. The patch lists the twenty fixtures in order along the truss, and the thirteenth is the first one misbehaving. So the signal reaches fixture twelve correctly, and the fault lies between fixture twelve's output and fixture thirteen's input, or in fixture twelve itself.

You look up at the truss. Fixture twelve's display is dark. Its power cable was knocked when a piece of scenery was moved, and it has lost power. On this model, an unpowered fixture does not pass DMX through to the next.

The rigger reseats the power connector. Fixture twelve boots, and a few seconds later fixtures thirteen to twenty snap to their positions. The designer continues the rehearsal. You write down that fixture twelve's power runs near the scenery track and ask for it to be dressed out of the way.

How to do it

1. List every input — every source of every signal the system receives, including returns from outside.
2. Find the core for each discipline and name its shape.
3. List every output — every destination and every feed.
4. Mark every two-way connection.
5. Mark the control path and what it controls.
6. Mark sync — clock, reference and timecode — and where each comes from.
7. Draw it on one page before you touch anything.

What goes wrong

Practice it

Answer before checking.

Drawing and Reading a System

A system drawing is signal flow written down, and it is how a system is communicated to everyone who did not build it. A good one lets a technician who has never seen the room find a fault in minutes; a bad one, or none, sends them crawling under the stage.

This chapter covers how block diagrams are drawn so that everybody reads them the same way, the other documents in a system's set and which question each answers, how to connect a system from its drawing and check the patch against it, and how to sketch a system when you were not given a drawing at all.

Block diagram conventions

A block diagram, also called a signal flow diagram or a system diagram, shows every device as a box and every connection as a line, arranged to show the flow rather than where anything physically is. The conventions are what make one readable by anyone.

Flow runs left to right. Sources are on the left, the core in the middle and destinations on the right, so reading the page is reading the signal. Where that is impossible, arrows show direction, and two-way connections have arrows at both ends or are labelled.

Each device is a box labelled with a device ID and a description: DSP-1, audio processor; TX-3, lectern transmitter. The ID is the same one written on the device's label in the rack. Inside the box, or at its edge, each connection is labelled with the port it uses — input 3, output 2, network port A — so a line lands on a specific connector, not just a device.

Each line carries a cable number that matches the label on both ends of the real cable. Different kinds of signal are drawn in different line types or colours: one for analog audio, one for digital audio, one for video, one for control, one for network. The drawing includes a legend that says which is which, because conventions vary between companies.

A drawing also has a title block: the project, the room, the drawing's name and number, who drew it, the date and a revision letter. The revision matters more than it looks. The drawing in your hand is only useful if it is the current one.

Reading a block diagram is the trace you already know, done on paper: find the source on the left, follow its line through every box, noting every port and cable number, to every destination on the right.

The family of system documents

A block diagram answers one question: where does the signal go? A full set of system documents answers several others, and a technician needs to know which to open.

A riser diagram shows where equipment physically is — which floor, which room, which wall plate, which ceiling position — and the cable paths between locations. It answers where to walk.

A rack elevation shows the front, and sometimes the back, of each equipment rack, with every device drawn in its rack units in the right position. It answers which box in the rack is DSP-1.

A cable schedule, or patch list, lists every cable by number with its type, length, source device and port, and destination device and port. It answers where the other end of cable 214 is.

An input list and output list, common in live audio, number every source and every feed with what it is and where it connects.

A network drawing and address list show which device plugs into which switch port, and the network address and name of every device.

Finally, an as-built set is the drawings corrected to show what was actually installed, which is never exactly what was designed. The as-built is what the next technician needs. A drawing that shows the design and not the build is a map of a place that does not exist.

Live events often compress all of this into a few pages — an input list, a patch sheet, a one-page flow diagram and a rack photo — and that is perfectly sound, as long as it is current and the labels in the room match it.

Connecting a system from its drawing

Most faults in a new system are created while it is being connected. The discipline that prevents them is simple: connect from the drawing, one line at a time, and check the patch against the drawing before anything is switched on.

Work from the cable schedule or the drawing, and connect cables in the order they are listed. Label both ends of each cable before it is connected, with the number the drawing gives it. Plug into the exact port the drawing names, not the nearest free one. Mark each line on a printed copy as it is done, so an interruption does not leave anybody guessing which were finished.

Then check the patch against the drawing. A second person, ideally, reads the drawing aloud and the first confirms each connection at the connector: cable 214, DSP-1 output 3, to AMP-2 input 1. Where the room differs from the drawing, one of them is wrong, and the answer is decided and written down, not left.

Only then does power go on, and only then does the system get tested with signals. A system that has been checked against its drawing before power-up has its faults found at the connector, where they are cheap, rather than during the show.

Sketching a system you were not given a drawing for

Most small jobs have no drawing. The technician who sketches one in five minutes, before anything goes wrong, is usually the one who fixes it when it does.

The sketch does not need to be neat. Take a page in the notebook. Down the left side, write the sources as you find them. Down the right side, the destinations. In the middle, the boxes that route and process. Draw lines between them as you trace each cable, and write on each line what kind of signal it is and which port it uses at each end. Add the control path in a different pen, or dashed. Mark the two-way connections. Write the settings that matter next to each box: the input a laptop is on, the gain of the lectern microphone, the EDID set on the switcher.

This takes minutes on a small system, and it does three things. It makes you look at every connection once, which finds a surprising number of faults before power-up. It gives you a map to trace on when something fails. And it gives the next person, or you next year, the drawing the job never had.

On a larger system with no documentation, the same sketch is done one discipline at a time, and the core of each is drawn first, because everything else connects to it.

Which document answers which question

What a readable block diagram shows

The conventions that let anybody read a drawing they did not make.

On every page

• Flow left to right, sources to destinations.
• A box for each device, with a device ID and description.
• Port labels where each line lands.
• A cable number on every line, matching the real label.
• A line type or colour per signal type, and a legend.
• Direction arrows where flow is not obvious, and on two-way lines.
• A title block with the drawing's name, date and revision.

On the job

A new client, a small university lecture theatre, has called because the ceiling microphones stopped working in the video calls a lecturer runs. There is no drawing, and the installer has gone out of business.

Before touching anything you spend ten minutes sketching. Sources on the left: two ceiling microphones, a lectern microphone, the lectern computer, a laptop input at the lectern. Destinations on the right: the projector, two ceiling loudspeakers, and the computer's video call software. In the middle, in the rack, a DSP and a small video switcher, and a control processor behind a touch panel.

Tracing each cable into the sketch, you find the ceiling microphones on DSP inputs 1 and 2, the lectern microphone on input 3, and a USB cable from the DSP to the computer. You write the DSP's USB channels on the sketch: one pair into the computer as its microphone, one pair out from the computer to the room.

Then you check the computer's settings. Its audio input is set to the laptop input's HDMI audio, not the DSP. An operating system update reset it. The microphones were never broken; the call software was listening to a different source.

You set the input back, test a call with a colleague, and leave the sketch in a plastic sleeve in the rack with today's date on it, the settings written beside each box, and the note that the computer's audio input resets after updates.

How to do it

1. Print the current revision of the drawing and cable schedule.
2. Label both ends of every cable with its number before connecting it.
3. Connect in schedule order, to the exact ports named.
4. Mark each connection on the printed copy as it is made.
5. Check the whole patch against the drawing, connection by connection, ideally with a second person.
6. Resolve every difference and write the decision on the drawing.
7. Power up, test, and mark up the drawing as built.

What goes wrong

Practice it

Answer before checking.

Troubleshooting & Thinking in Flow

Signal flow's biggest payoff: find any fault, and think like an AV professional.

Tracing to troubleshoot

The most powerful payoff of signal flow is troubleshooting: a fault is simply the point where a signal stops travelling from source to destination, so you find it by tracing the flow. Start where you know the signal is good and check each stage moving towards where it is missing (or work backwards from the dead destination), until you find the exact stage where the signal disappears — the fault lies between the last point with signal and the first without. This methodical tracing finds any fault in any system, because every fault is a break in a flow you can follow. It transforms troubleshooting from guesswork into a reliable process.

This works precisely because you understand signal flow: knowing the chain and what is upstream and downstream of each point lets you trace systematically rather than randomly swapping things. The signal-flow-fluent professional fixes problems calmly and quickly by following the flow to the break, in any discipline. This is the same systematic method the AV Troubleshooting Methodology book develops further, and it rests entirely on the signal-flow understanding this book builds. Master signal flow, and you can troubleshoot anything.

Thinking in signal flow

Ultimately, signal flow is a way of thinking that defines a capable AV professional. You see every system as flows from sources to destinations; you instinctively know what is upstream and downstream; you understand systems as inputs, core, and outputs; you build by connecting flows correctly, operate by understanding how signals move, and troubleshoot by tracing them. This signal-flow thinking is the foundation beneath all AV competence, which is why it comes first and why this concept recurs through every other book in the series. It is the mental model that makes everything else make sense.

Carry this thinking into everything you do in AV. Whatever the gear, whatever the discipline, whatever the scale, ask: where does the signal start, where does it go, what does it pass through, what is upstream and downstream, how is the system architected. These questions, answered fluently, are what it means to understand AV. Master signal flow deeply — as this book has built — and you have the foundation to learn, operate, design, and troubleshoot anything in the field. Signal flow is the heart of AV competence.

Practical sign-off

Signal-flow mastery is shown on real systems. The learner traces signals through systems naming every stage, maps a system as inputs-core-outputs, and troubleshoots a fault by tracing the flow. A mentor signs off when the learner thinks fluently in signal flow.

• Traced a signal source to destination naming every stage
• Identified upstream and downstream of any point in a system
• Mapped a system's architecture as inputs, core, and outputs
• Troubleshot a fault by tracing the flow to the break

The sign-off now covers the whole of the book, not only its first idea. In addition to the four items above, the learner demonstrates each of these on a real system, and a mentor watches rather than being told:

• Identified the level, and balanced or unbalanced type, of every signal on a patch
• Set gain structure on a simple audio system and found the first stage to clip
• Traced a signal through a normalled patch bay, an insert and an aux send
• Brought a new video source into a system with the right format, EDID and HDCP settings
• Built a mix-minus for a remote contributor and tested it in headphones
• Traced a signal on a networked system from transmitter to every subscribed receiver
• Described a whole show as inputs, core and outputs for every discipline
• Connected a system from its drawing and checked the patch against it
• Sketched an undocumented system and verified it with test signals
• Found a fault using the half-split method, changing one thing at a time

Before you trace, define the symptom

The fastest trace starts before anybody touches a cable, with a precise description of what is wrong. "The sound is not working" is not a symptom; "the lectern microphone is silent in the room and working on the recording" is, and it has already located the fault.

Ask what exactly is missing or wrong, at which destination, from which source. Ask what does work, because every working path proves stages good. Ask when it started and what changed — somebody unplugged something, a laptop was swapped, the system was switched off overnight — because recent change is the most common cause of a new fault. Check the obvious stages that fail most often before tracing anything: power, mutes, the selected input, the fader, the volume on the device.

Then write the symptom down in one sentence. It keeps the trace honest, and it is what you will tell the person who asked.

The half-split, and other ways to go faster

Tracing from one end of a chain works, and on a long chain it is slow. The half-split method is faster.

Pick a point roughly in the middle of the chain between the last place the signal is known good and the destination where it is missing, and check there. If the signal is present, the fault is in the downstream half; if not, the upstream half. Pick the middle of the remaining half and check again. A chain of sixteen stages takes four checks to reduce to one stage, where tracing from the start could take sixteen.

Choose checkpoints that are easy to reach: a patch bay, a console meter, a processor's input meter, a monitor output on a switcher. The best checkpoint is the one that proves the most stages at once for the least effort.

Known-good substitution is the other fast tool. Replace a suspect stage with one known to work — a cable, a source, a microphone, a laptop — and see whether the fault moves. If it does, the stage you replaced was the fault. If it does not, that stage is proven good and you have learned something.

Bypassing is its relation. Remove a stage from the chain entirely — plug the source past the extender, take the insert out, route around the scaler — and see whether the fault disappears.

Whatever the method, change one thing at a time and note what you changed. Changing three things at once can fix a fault without telling you which one it was, or break something else while you are looking.

Test signals and reference sources

A trace is much easier with a signal you control and trust than with a presenter who is not there yet or a laptop whose settings you do not know.

For audio, a tone generator produces a steady sine wave at a known level, which is perfect for checking level and continuity on each channel. Pink noise, a hissing sound with equal energy in every octave, is used for checking loudspeakers, because it exercises the whole frequency range and a missing driver or wrong polarity is easy to hear. Most consoles and processors can generate both, and a phone app can play them. A talkback microphone or a known-good playback track is the everyday reference.

For video, a test pattern generator produces colour bars, grids and resolution charts in a known format, and many switchers and processors can generate them too. A pattern shows immediately whether the right format arrives, whether the picture is scaled or cropped, and whether colours and levels are right, in a way that slides cannot.

For control and networks, the routing software's device list, a device's own status pages and link lights on switches are the references.

The same test signals are used to verify a system before anybody needs it. A system is not ready because each device lights up. It is ready when each input has been seen or heard at every output it should reach, with a known signal, and the result written down against the drawing. That is how a fault is found at three in the afternoon instead of at the moment the show needs it.

Hum, buzz and ground loops

A steady hum or buzz under the sound is one of the most common faults in audio and one of the least understood, because it is not in any single device. It is in the way the system's devices are connected together.

Every piece of mains-powered equipment is connected to earth for safety, through its power cable. Audio cables with shields connect devices together as well. When two devices are earthed at points with slightly different electrical potential — different circuits, different parts of a building — a small current flows round the loop formed by the power earths and the audio shield. That current flows in the shield of an audio cable and becomes hum in the signal, at the mains frequency and its harmonics. That is a ground loop.

Ground loops are a signal flow fault and are found the same way. A hum that appears when a particular device is connected and disappears when it is disconnected points to the loop through that device's connections. Unbalanced connections suffer far more than balanced ones. A laptop on its charger into a console, a video projector connected to the audio system by its HDMI and its own power, and an amplifier rack on a different power distribution to the console are classic examples.

The safe fixes break the loop in the signal path, never in the mains earth. An isolation transformer, or a DI box with a ground lift switch, breaks the audio shield's connection between the two devices while passing the signal. Balanced connections instead of unbalanced ones reduce the problem. Powering the related audio equipment from the same power distribution, arranged by the people responsible for power, often removes it.

The unsafe fix is removing or defeating the safety earth on a mains plug. It may stop the hum, and it removes the protection that keeps a device's metal case from becoming live in a fault. It must never be done, and if the only thing that stops a hum is a change to mains earthing, the fault has left a technician's hands and belongs to a qualified electrician.

Power-up and power-down order

The order in which a system is switched on and off follows the signal flow, and getting it wrong is how loudspeakers are damaged and ears are hurt.

When a device powers up or down, its outputs can produce a thump or a burst of noise. If an amplifier or powered loudspeaker is already on when that happens upstream, the thump is amplified and sent to the loudspeakers at full power.

So a system powers up from source to destination: sources and processing first — playback, consoles, processors — and amplifiers and powered loudspeakers last, once everything upstream has settled. It powers down in the reverse order: amplifiers and powered loudspeakers first, and everything else after them. Put simply, amplifiers last on and first off.

Many installed systems have a power sequencer that does this automatically, switching outlets one after another with a delay. Knowing the order still matters, because on a show, somebody always switches one thing off to reset it, and that one thing is upstream of loudspeakers that are still on.

Where faults usually are

A first place to look, by symptom. Every one is confirmed by tracing.

The half-split, in four lines

• Find the last known good point and the first known bad point.
• Check in the middle.
• Keep the half where the fault must be.
• Repeat until one stage remains.

Power order

• On — sources, processing, then amplifiers and powered loudspeakers last.
• Off — amplifiers and powered loudspeakers first, then everything else.

On the job

A corporate gala dinner in a hotel ballroom. Ten minutes into the first speech, the audio engineer calls on comms: a loud hum has appeared in the room, and it was not there at sound check.

You define the symptom before moving. A steady hum at mains frequency, in the room loudspeakers, constant whether anybody speaks or not. The console's main meters show a small steady level with every input muted, so the hum is getting into the system at or before the console's outputs, not in the loudspeaker processing.

What changed? The engineer thinks for a second. The client's video team plugged a laptop into the console for the award playback during the break, on an unbalanced lead from the laptop's headphone output, with the laptop on its charger.

You mute that channel. The hum stays, because the loop is through the cable's shield, not the channel. You ask the video team to unplug the laptop's charger for a moment. The hum disappears. The ground loop runs through the laptop's power earth and the unbalanced audio lead.

The laptop needs its charger for a two-hour event, so the charger goes back in, and a DI box with its ground lift engaged goes between the laptop and the console. The hum is gone and the playback is balanced and clean. At no point does anybody touch a mains plug's earth, and you write the DI into the patch sheet for tomorrow's show.

How to do it

1. Define the symptom in one sentence — what, where, from which source.
2. Ask what works and what changed.
3. Check the obvious stages first — power, mute, input selection, faders.
4. On paper, mark the last known good point and the first known bad point.
5. Half-split between them at easy checkpoints, using meters or test signals.
6. Substitute or bypass the suspect stage, changing one thing at a time.
7. Fix the cause, then retest the whole path.
8. Write down what it was and what you changed.

What goes wrong

Practice it

Answer before checking.

Glossary

What the gear actually looks like

Every device named in this book, in one place. Recognition is the whole point of Chapter 4 — use this page to attach a picture to each name before you meet it on a dock at six in the morning.

Audio

Dynamic microphone

Condenser microphone

Wireless handheld

Radio rack

Mixing console

Stage box / snake

Power amplifier

Main loudspeaker

Subwoofer

Stage monitor wedge

In-ear monitors

DI box

Video

Camera

Video switcher

Scaler / processor

Projector

LED wall panel

Confidence monitor

Lighting & control

Conventional fixture

Moving-head fixture

Lighting console

Dimmer

Show controller

Media server

Networking & infrastructure

Network switch

Patch bay

Equipment rack

Power distribution

Cable tester

A properly coiled cable

Connectors, close up

XLR

TRS / TS ¼-inch

SDI on BNC

HDMI

Cat5e / Cat6 (RJ45)

Fiber optic

DMX (5-pin XLR)

AC power — not signal