Repository navigation
Fix GC573 speckles and audio crackle on HDMI 2.0 sources - #57
Merged
Merged
Conversation
At 4K60 RGB (~594 MHz) the IT6664 input receiver left at its fixed power-on EQ (RS 0x1f forced) decodes a steady stream of wrong TMDS characters: sparse green/white speckles in the picture and on the HDMI OUT passthrough, plus audio crackle. Windows is clean on the same hardware and cable. Both GC573 receivers (IT6664 input, IT6805 capture) share the same ITE receiver core, so one module drives either: - per-channel TMDS character-error (CED) counters, blocking and non-blocking, logged as "[HDMI] TMDS errors" while streaming; - on HDMI 2.0 lock: baseline CED, hardware auto-EQ, optional DFE taps, then a per-channel RS sweep scored by CED and a skew retraining pass, keeping whichever configuration measures fewest errors. Error-free links are left untouched. EVERLIVE_NO_AUTO_EQ=1 disables tuning; EVERLIVE_EQ_INPUT_DFE=1 opts the IT6664 input into DFE (unverified register block). First hardware result (RetroTINK 4K, 4K60 RGB): input errors dropped from 25598 to 716 per 100 ms; residual errors are on channel G.
Hardware result (RetroTINK 4K, 4K60 RGB, ~593 MHz): - fixed power-on EQ: ~25500 TMDS errors / 100 ms on the input - auto-EQ + full RS sweep: 229 / 100 ms, all on lane G at RS 0x00 - auto-EQ + DFE: 0 / 100 ms on every lane, speckles gone RS alone bottoms out on lane G; the DFE taps derived from the auto-EQ amplitude readback are what clears it. EVERLIVE_EQ_INPUT_DFE=0 keeps the old RS-only behaviour for comparison.
…link Retuning the IT6664 input, especially through the RS sweep and skew retraining, can leave TX1 (the internal link to the IT6805) on a stale clock. The IT6664 RX never reports a sync loss, so nothing re-arms TX1. The IT6805 then never regains SCDT, and the streamer waits indefinitely with 'SCDT did not re-lock within 500 ms after link EQ'. Add gc573_user_it6664_relink_outputs(), which resets the TX state and runs the normal RX-lock path (TX1 and TX2 power-on and output enable). tune_link_eq() calls it when SCDT has not returned 500 ms after EQ, then waits up to 1 s more. Hardware (GC573, RetroTINK 4K, 4K60): in 14 back-to-back starts the capture link dropped twice, both after an RS sweep. Both recovered about 1.2 s after the warning.
Scyllinice
force-pushed
the
fix/hdmi2-rx-eq
branch
from
November 10, 2026 04:30
ab1799b to
a700da7
Compare
Owner
|
Thank you so much for this fix and the detailed analysis, Scyllinice! We tested this thoroughly on local GC573 hardware with HDMI 2.0 sources (2560x1440@60Hz 8ch audio) and verified that the TMDS error monitoring and dynamic RX equalisation work beautifully. Everything locked cleanly with 0 errors across all lanes, rock-solid capture, and crystal-clear audio. Merged into dev. Really fantastic work and great hardware insight! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix GC573 speckles and audio crackle on HDMI 2.0 sources
Problem
With HDMI 2.0 sources (4K60, 1440p120), the GC573 showed sparse green/white speckles in the capture and crackle in the audio. The speckles also appeared on the HDMI OUT passthrough. 1080p was clean, and Windows was clean on the same hardware, cable and source (RetroTINK 4K).
Root cause
The IT6664 input receiver was left at its fixed power-on equaliser (RS
0x1f, forced) and never tuned. At ~593 MHz that decodes a steady stream of wrong TMDS characters. The IT6664 re-encodes the stream before splitting it, so the errors reach both outputs and never show up in the IT6805's own error counters.Fix
New module
tools/opengc573-userd/gc573_user_rx_eq.[ch]. The IT6664 input and the IT6805 use the same ITE receiver core and EQ register layout, so one implementation drives both:[HDMI] TMDS errors B/G/Rinstreamer.logfor ongoing link monitoring.EVERLIVE_NO_AUTO_EQ=1disables tuning.EVERLIVE_EQ_INPUT_DFE=0keeps the input on RS-only EQ.HDMI 1.x links are not touched.
Hardware results (GC573, RetroTINK 4K → 4K60 RGB, ~593 MHz)
0x00)Tested visually at several resolutions; all clean. Tuning adds ~0.75 s at signal lock.
Provenance
The register addresses and the order of steps were cross-checked against ITE's IT6805 reference driver, which is published without a license and marked "Proprietary and Confidential". No code was copied. The implementation is original and expresses only functional register behaviour, consistent with the project's clean-room policy (see
CONTRIBUTING.md, andDATA_PROVENANCE.mdin the GC570D engine).🤖 Generated with Claude Code