Signal distribution and connectivity
A screen reading "No Signal", audio that never arrives, picture dropping out over a long cable, a network that stalls after the move to AV over IP. Most of these come not from the devices but from the handshake between them and from network configuration.
The screen says "No Signal" but the cable is plugged in.
A connected cable does not mean signal is flowing. Before any picture appears, HDMI performs a handshake: the source reads EDID — which resolutions and audio formats the display supports — over the DDC line, while a separate HPD line carries the “a display is attached” signal.
Long cables, poor terminations and extenders or switchers in the path can weaken those lines until the handshake fails. The video path can be perfectly sound and the screen still blank.
Copy protection uses the same DDC line, so the same faults break the HDCP handshake too. On top of that, HDCP 2.x content marked “Type 1” cannot be passed to an HDCP 1.x interface at all; only “Type 0” can. One older device in the chain can therefore kill the whole picture.
Simple switchers have a habit of their own: they drop DDC and HPD on every input change, and some displays then show nothing until they are power-cycled.
Extron’s recommendation is clear: manage EDID at the device closest to the source, and document the EDID strategy at design time. Testing this during commissioning is the cheapest way to avoid the “it worked yesterday” call six months after handover.
We get picture but no sound. Sometimes the sound is distorted.
Two separate faults get filed under one heading here.
If there is no audio at all: some projectors and panels without speakers declare no audio capability in their EDID. The source reads that as “this display takes no audio” and sends the sound to an analogue output instead — while the user starts checking cables. The fix is to present an EDID that includes the audio formats.
If the audio is distorted: the source may be set to a multichannel format the display cannot handle, such as Dolby Digital 5.1. The display cannot decode it and what comes out is broken. Setting the source to 2-channel PCM resolves most of these.
Where the audio genuinely needs to go somewhere else, the right tool is a de-embedder: it takes the audio out of the HDMI stream for the sound system and leaves the video going to the screen.
Picture drops out or sparkles over a long HDMI cable.
According to the HDMI Licensing Administrator, as data rates rose passive copper cables had to become either shorter or thicker. Active optical cables (AOC) break that trade-off: they can be both longer and thinner.
Cable maker Belden’s rule of thumb:
| Distance | Cable |
|---|---|
| up to ~4.5 m | Passive copper |
| beyond ~4.5 m | Cable with a signal booster chip |
| beyond ~15 m | Active optical cable (AOC) |
Treat this as a starting point rather than a limit table: the thresholds move down as resolution, frame rate and colour depth go up. A run carrying 4K60 4:4:4 is far harder than the same length carrying 1080p.
Past a certain distance the question stops being “which HDMI cable” and becomes “which transport” — HDBaseT or AV over IP. Choosing the right method for the distance is both cheaper and more durable than pushing a cable past what it can do.
Isn't one HDMI cable the same as another?
No, and the difference is printed on the label. HDMI’s official categories:
| Category | Bandwidth | Typical target |
|---|---|---|
| High Speed | 10.2 Gbps | 1080p / early 4K |
| Premium High Speed | 18 Gbps | 4K60 |
| Ultra High Speed | 48 Gbps | 8K60, 4K120 |
| Ultra96 | 96 Gbps | HDMI 2.2; 8K60 and 4K240 4:4:4 |
What matters is not only the number but who did the testing. Premium High Speed is tested at an authorised HDMI test centre and Ultra High Speed at an HDMI Forum test centre — and each length is tested separately. The label on the upper grades carries a QR code you can scan to confirm the cable really is certified.
HDMI LA warns about this directly: older labels have been printed on cables that were never tested, and at high frequencies shielding is critical for interference. “4K compatible” on the box tells you nothing on its own.
On an installation the cable can be the cheapest part and the biggest source of trouble. Scanning the QR on the label takes thirty seconds.
We extended over HDBaseT and get intermittent black screens.
HDBaseT can carry up to 100 m over category cable, but that figure is not universal — it depends on cable type and specification version. For 4K:
| Version | Cable | Reach |
|---|---|---|
| Spec 1.0 | Cat5e and above | 70 m |
| Spec 2.0 | Cat5e | 90 m |
| Spec 2.0 | Cat6 | 100 m |
| Spec 3.0 | Cat6a U/FTP recommended | 100 m (uncompressed 4K60 4:4:4) |
Running a device rated “up to 100 m” over 95 m of Cat5e is well outside the envelope. Intermittent black screens are exactly that symptom: the link is marginal and drops as temperature or interference changes.
Belden flags two further points: alien crosstalk has to be controlled, and shielded cable can introduce grounding problems in some installations — so “use shielded to be safe” is not automatically the right move.
Certifying the link with a proper tester during commissioning moves this fault from after handover to before it.
We moved to AV over IP and now the network is slow and video stutters.
AV traffic is real time and behaves unlike ordinary office traffic: it rests on multicast, PTP timing and QoS.
NETGEAR’s point is that the problem is usually not a shortage of bandwidth but configuration. Without IGMP snooping and a clear IGMP querier, multicast traffic behaves like broadcast and floods every port on the switch — the AV stream reaches every device, including those with nothing to do with AV. That is the usual source of “the network got slow”.
Shure recommends enabling IGMP snooping and a querier on multi-switch networks, with the core switch acting as the querier.
One caveat: not every AV over IP product uses multicast. On unicast systems some of this does not apply, so establish which architecture you are running first.
The practical approach is to design the AV network with the IT team, put it on its own VLAN, and define QoS from the start. AV traffic added to a network that was not prepared for it always looks like the culprit.
We get clicks and pops on Dante, and devices appear and disappear in Dante Controller.
Audinate traces these symptoms to one thing: loss of PTP clock sync. Dante devices lock to a shared clock; when that lock slips, audio clicks and devices drop off the list and come back.
The known triggers:
- Energy Efficient Ethernet (EEE) enabled on switches — both Audinate and Shure recommend turning it off
- Incorrect IGMP snooping configuration
- Mixing switches from different manufacturers
- IGMP incompatibility on Macs’ built-in Ethernet ports
- A clock source mismatch between a console or DSP and Dante
Shure also asks that “Filter Unregistered Multicast” is not enabled on the switch: when it is, it can block mDNS, PTP and Dante discovery traffic — that is, stop the devices finding each other.
Every item on that list is switch configuration. On a Dante network, choosing and configuring the switch matters as much as choosing the microphones.
Didn't find what you were looking for?
Describe your problem and we will answer from field experience. For questions about using the digital signage product, the Knowledge Base may be quicker.