 |
 |
This article addresses a common problem that we have seen with the implemention of AVMUTE.
Most source firmware designers write code that properly sets-up transmitting hardware to output Set_AVMUTE and Clear_AVMUTE instructions before and after timing changes, respectively. The problem is that frequently the source firmware fails to wait for the Set_AVMUTE to be actually transmitted-to and received-by the sink device before changing timing, thereby completely defeating the purpose of the AVMUTE function.
According to Section 5.3.6 of the HDMI v1.3 standard, "General Control packets indicating Set_AVMUTE or Clear_AVMUTE may only be transmitted between the active edge of VSYNC and 384 pixels following this edge." This means that AVMUTE cannot be set or cleared instantaneously - as many source product designers assume when writing to their transmitter's control registers. Instead, source firmware must SETUP transmitter logic to eventually send an AVMUTE change instruction and then wait for the active edge of a VERTICAL SYNC pulse to go by (at which point the AVMUTE set will actually be registered by the sink's receiving hardware) before making a TIMING CHANGE.
So our recommendation is:
After setting transmitter registers to output an updated GCP with Set_AVMUTE, source firmware should wait for a (few) vertical sync pulse(s) to occur before changing any timing. This is because the updated GCP with AVMUTE control is not normally output instantaneously, but is instead output at the prescribed time in vertical blanking. If timing changes are made before the transmitter has sent (and the sink has actually received) the updated GCP with Set_AVMUTE, then all benefits of this recommendation may be lost (e.g. audible pops and visual flashes may not be squelched and content protection system glitches may occur - leading to extended recovery time and random compliance test failures).
|
|
 |
