The long winding path to getting HDMI Audio working

But my notes assure me it has been only 8 or 9 days that it has taken me to get HDMI audio working, but it feels like a month!

Having spent a few days to get the HDMI video finally working recently, I was keen to get HDMI audio working as well, so that we could just cross the whole HDMI thing off the list of major outstanding tasks for the MEGA65.  It should have been easy, but turned out to be quite nasty for a variety of reasons, not the least of which was a little tiny typo... but more on that later.

The ADV7511 HDMI driver chip we are using supports audio as well as video, and of course we want to have the MEGA65 with with that, so that it is super-easy for people to plug a MEGA65 into their TV or monitor, and get sound as well as picture.  Having got the MEGA65 and MEGAphone prototypes working, I am beginning to get familiar with digital audio formats. 

I was expecting to use the same I2S audio format that the MEGAphone uses for various of its audio paths.  However, the MEGA65 R2 PCB has only SPDIF audio hooked up. No problem. After a bit of hunting around, I found a nice SPDIF implementation in VHDL that I could use.  It didn't take too much hassle to get that plumbed in and working. 

It was then also a bit of additional fiddling with ADV7511 I2C register settings (and research to find out what I wasn't setting) to get some audio coming out in test bitstreams. This took a bit longer than expected, because at first I didn't realise that I was hitting a rather weird problem: Enabling HDMI audio with the PAL video mode we are using caused the HDMI output to completely fail, i.e., the screen would go to sleep, as though there was no video signal. 

Once I figured out that that was happening and switched to using the NTSC mode to work on, I soon had reasonable audio.  I say reasonable, because it was quite recognisable, but also quite distorted. There were a number of small bugs here, as well as simply reducing the audio output level to a level that agreed with the ADV7511.  I also increased the sample rate to 192KHz, since HDMI supports that, and I figured it couldn't hurt.

What then followed was several long frustrating nights, as I tried to figure out what was going on with this crazy PAL video mode problem.  Why on earth would turning audio on with a PAL signal cause the signal to fail?  Why would a monitor even care whether the signal was PAL or NTSC when processing the audio?  These and many other questions kept flying through my head.

To help track the problem down, I reworked the whole HDMI I2C setup code, so that I could actually direct memory map the I2C registers, so that I could see what the ADV7511 was thinking about things, as well as trying to tweak any registers that seemed like they might be the culprit. It turned out that none of them were the cause, although I recall that I did improve a few of the settings along the way. It also meant that I wrote a nice little HDMI debug utility that shows the status of many of these registers, and reports on the detected video mode etc:

The PAL problem was at the time still causing me increasing frustration, as there was no apparent cause for it, as can be seen in the rather long github issue log as I tried various things.  So I resorted to asking for help on the Analog Devices forum, and then progressively mutating the NTSC video mode until it matched the PAL video mode, to try to find the actual cause. It was this last idea that finally let me solve the problem:  I had a typo in the VSYNC setup for the PAL video mode, that caused the VIC-IV to produce pixel data during the first line of VSYNC.

Once it started working, it was obviously a very great relief.  Commando sounds excellent.  I think there might be some minor problems with stereo and level normalisation causing some clipping due to DC bias on the digital samples. But those are all feel like achievable relatively small tasks, now that we have the fundamental audio working.