This is really a confirmation of the problems that were reported in:
https://ez.analog.com/video/f/q-a/5218/adv7513-issue-on-some-tv-with-bt-656-spdif
Basically using SPDIF audio on the ADV7511 with 480p/576p video modes (and possibly others with a 27MHz pixel clock?), the ADV7511 produces an audio stream that many TVs and devices don't like. Some just ignore the audio. Others refuse to even show an image. Those that show an image, tend to periodically lose lock and the display goes black for a second or two, while the TV/monitor regains lock. If the SPDIF audio TX is disabled, then these stability problems go away.
We have been looking at this for months, and yet to find a solution. Some important points:
1. It works on *some* monitors. This confirms that we are configuring the ADV7511 correctly to produce an audio-containing HDMI stream, that incorporates the SPDIF audio.
2. On the TVs that don't like the ADV7511's output, we can quite easily get HDMI with audio from other devices, e.g., a MimasA7 FPGA board which drives the HDMI directly from four pairs of differential pins direct from the FPGA. Thus it isn't the TV.
From this, we deduce that either we have some incorrect setting on the ADV7511's setup, or the ADV7511 really does have a problem with this combination of SPDIF and 480p/576p video modes.
We are using a custom PCB that has no application processor, thus we can't use the official software driver. If, however, you can provide the list of register settings that it applies, or whatever other magic it does, we would be glad to try that. Holding back such information, however, will just help push us away from your products to something else -- like implementing the same as what the MimasA7 board has, which would also be much cheaper in production. Also, with the COVID19 fun, getting an ADV7511 eval board to us is going to take a long time -- longer thant it would for us to redesign our board to not need the ADV7511. Thus if I request the purchase of one, that will cause the decision makers to instruct me to drop the ADV7511 immediately.
Basically we have to make the decision as to whether finding a way to make the ADV7511 work properly in this situation, or whether it is cheaper and faster for us to re-spin the part of the PCB to match what the MimasA7 board does. We already have test engineers working to verify the compatibility of that solution, because we don't really have any more time to waste on making the ADV7511 behave properly. This is our last-ditch effort to find a solution, and thus it would be in our collective interest to provide as much information as you can, including about the initialisation sequence that the official software driver does -- or at least a pointer to the source code for it, so that we can work that out for ourselves.
To see how we are initialising the device, please see:
https://github.com/MEGA65/mega65-core/blob/138-hdmi-audio-27mhz/src/vhdl/hdmi_i2c.vhdl
The table of register writes begins around line 160. Each 16-bit value is a register/value pair, e.g., x"4110" means "write 0x10 into register 0x41".
N/CTS values have been checked multiple times for the 44.1KHz sample rate + 27Mz pixel clock.
The SPDIF audio TX has been checked under simulation and proved at the ADV7511's pin to confirm that it is exactly 44.1KHz.
When I get the chance a little later, I intend to modify our design to produce a video mode with a higher resolution, to see if we can provide conclusive evidence that it is SPDIF + video mode combination that is the problem. But other than that, we have run out of things to check. We would like to be able to proceed with the ADV7511, but unless we find a solution, we just don't have any possibility of retaining it in our design.
Can someone with the eval board please setup a 480p/576p 27MHz pixel clock video mode with 44.1KHz SPDIF audio, and try it on any Samsung TVs they have around, to see if they can also reproduce the problem?
Paul.
