AV Troubleshooting Methodology

Effective AV troubleshooting is not guesswork — it is a structured process of eliminating variables one at a time until the fault is isolated to a single component or configuration. The most common mistake is replacing hardware before the fault is understood. A disciplined methodology saves time, avoids unnecessary parts swaps, and produces a documented root cause that prevents recurrence.

1. Reproduce the fault. Before touching anything, verify the problem is real and repeatable. Ask the user to demonstrate it. Note exact conditions: which input, which output, what time of day, whether it is constant or intermittent. Intermittent faults are harder — try to identify a trigger (source device connected, specific resolution, certain time of day, heavy network load).

2. Define the signal chain. Trace every component between source and destination: source device → cable → transmitter/wall plate → switcher/matrix → cable → receiver/decoder → display. Also include: power, control system, network (if applicable). The fault lives somewhere in this chain.

3. Divide and conquer. Test at the midpoint of the chain. If the midpoint works, the fault is downstream. If not, it is upstream. Repeat until isolated. This binary search approach is faster than testing each component sequentially.

4. Substitute known-good. Once the fault is isolated to a segment, substitute each component with a known-good equivalent: different cable, different output card, different display input. The substitution that fixes the problem identifies the faulty component.

5. Document the root cause. Before leaving the site, document what failed, why, and what was done. Update the as-built if configuration changed. This creates a service history that helps future technicians.

HDMI issues are the most common AV fault category. Most are caused by EDID negotiation failure, HDCP authentication failure, or cable/connector degradation.

Step 1 — Verify source is outputting. Connect the source directly to a known-good display with a short HDMI cable. If it works direct, the issue is in the signal chain. If it does not, the source or its output is faulty.

Step 2 — Check EDID. EDID is the display capability data the source reads to determine output resolution. If a switcher or extender presents incorrect EDID, the source may output a resolution the display cannot handle, producing a black screen. Set the switcher input to a safe fixed EDID (1080p60, no HDR) to test. See video/edid-management.

Step 3 — Check HDCP. HDCP authentication must complete for protected content to display. If any component does not support the required HDCP version (2.2 for 4K protected content), the signal is blocked. Test with an unprotected source (laptop desktop, not streaming) — if unprotected works but protected does not, HDCP is the cause. See video/hdcp.

Step 4 — Cable and connector. HDMI cables fail silently — 4K, HDR, and high refresh rate signals are more susceptible than 1080p. Substitute a known-good short cable at each segment. Check for bent pins, debris, and loose connections at wall plates.

Step 5 — Switcher output port. Test from a different output port. If another port works, the original port is faulty.

Usually HDCP re-authentication cycling or marginal cable integrity. HDCP re-authenticates when the source detects a change — a routing switch, display going to standby, or intermittent cable contact triggers re-authentication, which appears as a brief black flash.

Fix: Configure the switcher to maintain HDCP authentication on all outputs continuously (most switchers have an "HDCP always on" or "HDCP force" mode). For cable integrity issues, substitute a shorter cable to confirm, then run a higher-quality cable for the permanent fix.

The source negotiated a resolution that does not match the display. Check the EDID configuration at the switcher input — if the EDID advertises 4K and the display is 1080p, the source outputs 4K and the display scales or crops it. Set the switcher input EDID to match the destination display's native resolution.

Step 1 — Verify HDMI audio is enabled on the source. Windows and Mac can have HDMI audio output disabled in system sound settings. Confirm the audio output device is set to the HDMI/DisplayPort output, not the laptop speakers or headphone jack.

Step 2 — Check audio de-embedding. If audio is being extracted at a switcher or de-embedder, verify the de-embedder is set to the correct input and the output routing is correct. Many de-embedders have per-input audio routing — a switched input may not automatically follow.

Step 3 — Check DSP routing. In the DSP (Q-SYS, Biamp, Extron DMP), check input metering. If metering shows signal, trace the routing to the output. If metering shows no signal, the fault is upstream of the DSP.

Step 4 — Check amplifier. Verify the amplifier is powered, not in fault condition (check front panel status LED), and input sensitivity is set correctly. Gain trim accidentally turned down is a common cause of "no audio" that appears to be a system fault.

Ground loop is the most common cause — two pieces of equipment on different electrical circuits develop a ground potential difference that induces 60 Hz hum into the signal.

Diagnosis: Disconnect inputs one at a time at the DSP. When disconnecting a specific input eliminates the hum, that input's source is involved in the loop.

Fix options:

Jensen transformer (ISO-MAX or equivalent) on the offending input — breaks the ground while passing audio
Ground lift on balanced connections — lift pin 1 at one end only; do not float both ends
Move source equipment to same electrical circuit as the DSP/amplifier rack
Extron FOX3 fiber extension eliminates ground loops by design — use for long-distance connections with isolation requirements

AEC (Acoustic Echo Cancellation) is not working correctly. Common causes:

AEC reference not connected — The DSP's AEC block requires the loudspeaker output routed back as a reference signal. If this is not wired in the DSP design, AEC cannot cancel echo. Verify the AEC reference path in Q-SYS or Biamp design.
Level mismatch — The reference level must be calibrated to match actual loudspeaker output. Too high or too low reference causes AEC failure or residual echo.
Non-linear processing on reference — Any compression or AGC between the AEC reference tap and the loudspeaker must also be applied to the reference signal, or the AEC filter model fails.
Speaker too close to microphone — Verify microphone placement per manufacturer guidelines; large rooms with high RT60 may exceed AEC tail length.

See audio/echo-cancellation and glossary/aec.

Step 1 — Check network connectivity. Ping the device IP from a PC on the same VLAN. No response means the device is unreachable — check switch port link, VLAN membership, and cable. Ping success but no Dante discovery means mDNS may be blocked or the device is on a different VLAN.

Step 2 — Verify all devices are on the same VLAN. Dante discovery uses mDNS, which does not cross VLAN boundaries. All Dante devices must be on the same Layer 2 VLAN. If devices are on different VLANs without Dante Domain Manager, they cannot discover each other. See networking/dante-domain-manager.

Step 3 — Verify IGMP snooping. Dante multicast floods all ports if IGMP snooping is disabled, saturating links and causing dropouts. Verify IGMP snooping is enabled at the VLAN level on all switches. Check the switch IGMP group table — each active Dante receiver should show a registered group.

Step 4 — Check clock status. Open Dante Controller → Clock Status view. All devices should show as PTP slaves with low offset (< 1 µs) from the grandmaster. High offset or clock errors cause audio artifacts. If a laptop running Dante Virtual Soundcard is the grandmaster, CPU load causes clock instability — designate a stable hardware device as preferred clock master in Dante Device Manager.

Step 5 — Check QoS. Dante marks packets DSCP EF (46). Without QoS, IT traffic delays Dante packets causing dropouts. Verify QoS is configured on all switch ports in the Dante path. See networking/qos-for-audio.

Check Dante Controller → Network Status view. Even 0.1% packet loss causes audible glitches. Look for elevated latency (above 1 ms) and any packet loss. Run the monitor for 15–30 minutes — intermittent loss is common at peak network load.

Check sample rate — all Dante devices must be at the same sample rate (48 kHz for most installed AV). A device at 44.1 kHz shows in Dante Controller but all routes to/from it are inactive.

Step 1 — Network connectivity. Ping the panel IP. No response: check cable, switch port link, and PoE delivery status. If PoE-powered, the switch port PoE indicator should show active delivery.

Step 2 — IP ID mismatch (Crestron). If ping succeeds but the panel does not communicate, verify the panel's IP ID matches the SIMPL program assignment. Mismatched IP IDs cause the panel to connect to the network but not bind to the program.

Step 3 — Control processor program status. Connect via Crestron Toolbox → System Info. Verify the program is running — not stopped or crashed. Check the error log for exceptions. A crashed program leaves the panel connected to the network but with no functional response.

Step 4 — Inter-VLAN firewall. If the panel is on a corporate VLAN and the processor is on an AV VLAN, verify firewall rules allow Crestron CIP (port 41794) between the two subnets.

Step 1 — Verify baud rate and parameters. Mismatched communication parameters are the most common RS-232 failure. Confirm baud rate, data bits, parity, stop bits, and flow control against the device's installation manual — do not assume 9600 8N1.

Step 2 — Verify cable wiring. RS-232 requires TX → RX crossing. Pin 2 (RX) on the device connects to pin 3 (TX) from the controller, and pin 3 (TX) on the device connects to pin 2 (RX) from the controller. Pin 5 is ground. Some devices require null-modem (crossed) wiring.

Step 3 — Monitor port traffic. Use Crestron Toolbox Port Monitor or Extron Toolbelt RS-232 monitor to verify commands are actually being transmitted. If the command appears in the monitor but no response comes back, the parameters or command format are wrong. If no command appears, the control program is not executing the send.

Step 4 — Verify command terminator. RS-232 commands are terminator-sensitive. A display expecting \r will ignore a command terminated with \r\n. Check the device protocol document for the exact terminator character.

Check lamp hours — most projectors lock out near the lamp life limit (2,000–5,000 hours). Access the projector menu or send a status query via RS-232 (\x02LAMP?\x03 for many Sony/NEC models) to read lamp hours. Replace the lamp if hours are at or near limit; reset the lamp hour counter after replacement. Laser projectors degrade gradually rather than failing abruptly and have rated lives of 20,000+ hours.

Test manual power via remote — if it powers on manually but not via RS-232/IP, the control path is the issue. Verify the display has RS-232 standby mode or "LAN Control" enabled in its settings; many displays power down the RS-232 port in ECO/deep sleep mode, making them unreachable until they receive power via the display's own IR receiver or front button.

Verify the projector is level and perpendicular to the screen — physical misalignment causes geometry distortion that keystone correction cannot fully compensate. Run projector auto-setup if available. For color calibration, set color temperature to D65 (6500K) for most presentation environments and verify the input signal is not being color-converted by the source (some laptops apply ICC profiles that shift color).

Intermittent faults are the hardest to diagnose because the system appears normal on arrival. Strategies:

Review control system logs. Q-SYS, Crestron (Toolbox error log), and Extron (Toolbelt Monitor) all maintain logs. Review entries from the period when faults occurred — look for repeated errors, connection drops, or exception messages.
Check for overheating. Rack temperatures above 40°C cause equipment to fault and recover intermittently. Check rack airflow, blanking panels, and fan operation. Touch the top of equipment in the rack — if it is too hot to keep your hand on, cooling is inadequate.
Monitor Dante in real time. Leave Dante Controller → Network Status running for 30 minutes. Even brief packet loss events appear in the monitor and correlate with audio glitches.
Check UPS and power. Intermittent power supply issues (failing UPS battery, loose IEC cable) cause random reboots. Check UPS battery health and verify all power connections in the rack are fully seated.
Reduce variables. Simplify the signal chain to minimum components, verify stability, then add components back one at a time until the fault returns.

Replacing hardware before diagnosing. Swapping a switcher because "it's probably the switcher" without testing the signal chain wastes time and may not fix the underlying problem. Isolate first, substitute second.
Skipping EDID as a variable. EDID issues account for a large fraction of "no signal" and "wrong resolution" calls. An EDID emulator ($30–$80) can confirm or rule out EDID as a cause faster than any other diagnostic step. Check EDID early in the diagnostic sequence, not as a last resort.
Testing only one end of an RS-232 cable. Pin 2 (RX) at the device must connect to pin 3 (TX) at the controller. Verifying the wiring at the controller end only confirms half the connection. Test the pinout at both connectors, or substitute a verified cable.
Assuming intermittent = cable. Cables are a common culprit for intermittent HDMI issues, but intermittent audio, control, or network problems have many other causes — overheating, HDCP cycling, clock instability, QoS misconfiguration. Identify which signal type is failing and test that type's specific failure conditions before blaming the cable.
Not verifying the fix. After making a change, verify the original fault no longer occurs. Test the exact scenario the user reported, including edge cases (switching sources, standby/wake cycles, heavy network load). A fix that works in testing but fails in real use is not a fix.
Leaving without documentation. A technician who fixes a fault but does not document it forces the next technician to diagnose from scratch. Note the root cause, what was changed, and any configuration details (EDID settings, HDCP mode, IP address changes) in the service record.

AV Troubleshooting Methodology

The Core Framework: Isolate, Substitute, Verify

HDMI and HDCP Failures

Symptom: Black screen, no signal

Symptom: Flickering or intermittent signal

Symptom: Wrong resolution / letterboxed image

Audio Dropouts and Failures

Symptom: No audio from HDMI source

Symptom: Hum or buzz in audio system

Symptom: Echo on conferencing system

Dante Network Audio Failures

Symptom: Dante device shows offline in Dante Controller

Symptom: Dante routes active but audio artifacts or intermittent dropout

Control System Failures

Symptom: Touchpanel shows offline / not communicating with processor

Symptom: RS-232 device not responding to control commands

Display and Projector Failures

Symptom: Projector lamp not igniting

Symptom: Display won't power on via control system

Symptom: Image geometry or color issues on projector

Intermittent Faults — Special Approach

Common Pitfalls