Post Go back to editing

ADV7619: no audio from recent-vintage Mac mini

We are having a problem receiving audio from a recent Mac mini using the ADV7619.

We successfully receive audio for all other sources, and other sinks we've tried have no trouble with audio from the Mac.  In fact, if we run the video from the Mac into a splitter, our device gets no audio but the other sync gets it just fine.  We are supplying the EDID in this case, which advertises basic audio support only.

We *are* receiving an I2S clock consistent with 48 KHz, sampling rate, but no audio samples.

Here is a partial register dump when connected to the Mac (although it is not part of this dump I checked and confirmed that we are in HDMI mode, not DVI):

[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:893]:HDMI map 0x04 = 0x23
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:894]:  Audio PLL locked = 0x01
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:898]:IO map 0x7E = 0x1c
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:899]:  Audio FIFO Overflow raw = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:900]:  Audio FIFO Near Overflow raw = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:904]:IO map 0x83 = 0x62
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:905]:  Audio FIFO Near Underflow raw = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:906]:  Audio flat line = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:907]:  New audio samp freq = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:908]:  Audio parity error = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:909]:  Audio mode change raw = 0x20
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:917]:HDMI map 0x12 = 0x02
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:918]:  Audio FIFO almost empty threshold = 0x02
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:922]:HDMI map 0x11 = 0x7d
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:923]:  Audio FIFO almost full threshold = 0x7d
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:927]:HDMI map 0x18 = 0x31
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:928]:  Audio sample packet detect = 0x01
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:929]:  DSD packet detect = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:930]:  DST audio packet detect = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:931]:  HBR audio packet detect = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:935]:HDMI map 0x6E = 0x04
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:936]:  MUX_SPDIF_TO_I2S_ENABLE = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:940]:HDMI map 0x6D = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:941]:  I2S_SPDIF_MAP_ROT = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:942]:  I2S_SPDIF_MAP_INV = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:946]:HDMI map 0x03 = 0x90
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:947]:  I2SBITWIDTH = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:948]:  I2SOUTMODE = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:952]:IO map 0x65 = 0x4e
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:953]:  AUDIO_CH_MD_RAW = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:957]:HDMI map 0x07 = 0xa5
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:958]:  AUDIO_CHANNEL_MODE = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:962]:HDMI map 0x1A = 0x80
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:963]:  MUTE_AUDIO = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:964]:  NOT_AUTO_UNMUTE = 0x00
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:968]:HDMI map 0x0F = 0x1f
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:969]:  AUDIO_MUTE_SPEED = 0x0f
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:973]:IO map 0x65 = 0x4e
[2020-07-30 18:04:40 EDT]:[WRN]:[rap]:[libkx4_video]:[AdvChip.cpp:974]:  CS_DATA_VALID_RAW = 0x00

That last one seems important.  The thing is, when I connect an HDMI analyzer to the other branch of a splitter, it does seem to be receiving channel status, and as I said every other sink we connect to the Mac seems to have no trouble with the audio.

Would appreciate any suggestions on what to look at to sort this out.

  • Hi,

     NEW_SAMP_RT_RAW flag does not trigger if CS_DATA_VALID_RAW is set to 0. This prevents the notification of a change from a valid to an invalid audio sampling frequency readback in the channel status bits, and vice versa.

    The NEW_SAMP_RATE interrupt will trigger if the CS_DATA[27:24] bits gathered differs in two consecutive reads.
    However, NEW_SAMP_RATE is not guaranteed to be valid uness CS_DATA_VALID is high. In general, it is best to only look at the CS_DATA when CS_DATA_VALID is high. 



  • Thank you for your response.

    The question we need to answer is why the CS_DATA_VALID bit is low, when every other sink device we connect to the source seems to be have no problem with the audio.  Is there any way to dig into the registers to see what might be happening?

    Or, if all else fails, is it possible to force the chip to output audio even if CS_DATA_VALID is low?

  • Do you have our ADV7619 evaluation board?


  • No, we don't.

    However, we have "sort of" isolated the problem based on this other Engineer Zone thread:  Our situation appears to be identical to the one described there.

    As in that thread, clearing bits 2 and 3 of HDMI register 0x14 restore our audio.

    However, also like the original poster there, we don't understand the function of those two bits, and are uncertain whether it is safe to always clear them, or whether we only need to clear one of them, or what exactly.  A description is given for bit 2, but we also are not processing HDCP-encrypted content, so don't understand why that bit would be set.  And bit 3 remains a mystery.

    Can you shed any light on this?

  • Our ability to support custom hardware/software for the ADV7619 is very limited at this time. 

    If you could reproduce the issue on our ADV7619 evaluation board hardware/software, then we could rule out some issue with the custom hardware/software.