No audio from HDMI (MCP89 / Geforce 320M): Reason: no connected devices detected

[lintweaker]

I cannot get sound through HDMI working on my new 2010 mac mini (MCP89 / Geforce 320M).
Checking the kernel logs it seems that the connected device (either a TV or Receiver) is not detected. In the bug I reported in Fedora bugzilla (#610873) they mentioned that the ELD information must be filled by the graphics driver.

Dmesg reports:
HDMI hot plug event: Pin=5 Presence_Detect=1 ELD_Valid=0
HDMI hot plug event: Pin=5 Presence_Detect=0 ELD_Valid=1

Instead of:
HDMI hot plug event: Pin=5 Presence_Detect=1 ELD_Valid=0
HDMI hot plug event: Pin=5 Presence_Detect=1 ELD_Valid=1
HDMI: detected monitor RX-V1065
at connection type HDMI
HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200 176400 192000 384000, bits = 16 20
HDMI: supports coding type LPCM: channels = 8, rates = 44100 48000 88200 176400 192000 384000, bits = 16 20
HDMI: supports coding type AC-3: channels = 6, rates = 44100 48000 88200, max bitrate = 640000
HDMI: supports coding type DTS: channels = 7, rates = 44100 48000 88200 176400 192000, max bitrate = 1536000
HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 48000
HDMI: supports coding type E-AC-3/DD (Dolby Digital Plus): channels = 8, rates = 48000 88200
HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 88200 192000
HDMI: supports coding type DTS-HD: channels = 8, rates = 88200 192000

The main problem seems to be that there a connected TV of Receiver is not
detected. None of the /proc/asound/eld#?.0 lists a connected device:

[kramer@macmini2010 card0]$ more eld#3.0
monitor_present 0
eld_valid 0
monitor_name
connection_type HDMI
eld_version [0x0] reserved
edid_version [0x0] no CEA EDID Timing Extension block present
manufacture_id 0x0
product_id 0x0
port_id 0x0
support_hdcp 0
support_ai 0
audio_sync_delay 0
speakers [0x0]
sad_count 0

[kramer@macmini2010 card0]$ more eld#4.0
monitor_present 0
eld_valid 1
monitor_name
connection_type HDMI
eld_version [0x0] reserved
edid_version [0x0] no CEA EDID Timing Extension block present
manufacture_id 0x0
product_id 0x0
port_id 0x0
support_hdcp 0
support_ai 0
audio_sync_delay 0
speakers [0x0]
sad_count 0

[kramer@macmini2010 card0]$ more eld#5.0
monitor_present 0
eld_valid 0
monitor_name
connection_type HDMI
eld_version [0x0] reserved
edid_version [0x0] no CEA EDID Timing Extension block present
manufacture_id 0x0
product_id 0x0
port_id 0x0
support_hdcp 0
support_ai 0
audio_sync_delay 0
speakers [0x0]
sad_count 0

Any help would be very appreciated.

Output of alsa-info.sh:
http://www.alsa-project.org/db/?f=29...a61cad25d10904

From a working system for comparison (GT220):
http://www.alsa-project.org/db/?f=cc...f8d11dafb30324

[Stephen Warren]

I'm not at all familiar with audio issues, but I'll try to help...

On the problematic card, can you reproduce the problem, run nvidia-settings, go to the "X Server Display Configuration" page, and click "Detect Displays". Does this show all the connected displays correctly?

There is also a page for each active display device near the bottom of the list. On this page is an "Acquire EDID" button. Can you save the EDIDs of all your monitor(s) and attach them here; then we can double-check that the EDID contains the correct audio data.

You mentioned that you have two GPUs and one works, one doesn't. Does the problematic behaviour follow the GPU or the display device? (In other words, try swapping the monitors, is the MCP89 always problematic, or is just one of your monitors problematic).

Thanks.

[lintweaker]

Thanks for your support. Detecting of the connected display is working fine. I have acquired the EDIDs for the various combinations of my machines and connected displays. I have attached these EDIDs.

(on the mac mini). I have disabled twinview so nvidia-settings reports (from nvidia-settings->X Server Display Configuration)
Unable to load X Server Display Configuration page:
nvidia-settings currently does not support scanout screens (0) that have dynamic
twinview disabled.

But it reports the connected TV as Panasonic-TV on DFP-1

Connection: MCP89 HDMI->Panasonic TV (my mac mini directly connected to the TV)
EDID file: mcp89-hdmi-panasonic-tv.edid.bin

(on the mac mini)

Connection: MCP89 HDMI->RX-V1065->Panasonic TV (my mac mini connected to my receiver which is connected to my TV)
EDID file: mcp89-hdmi-receiver-panasonic-tv.edid.bin

Retest with Dynamic Twinview enabled.

Connection: MCP89 HDMI->RX-V1065-Panasonic TV
EDID file: mcp89-hmdi-receiver-panasonic-tv-edid-twinview-enabled.bin

(on the machine with GT220)
Connection: GT220-HDMI->RX-V1065->Panasonic TV
EDID file: gt220-hmdi-receiver-panasonic-tv.edid.bin

I have checked the EDIDs with edid-decode, I could not find anything amiss (too bad). I hope you can find the culprit.

[Stephen Warren]

It looks like you're using driver 195.36.31. There have been a number of changes related to audio-over-HDMI since then. Can you please try driver 256.35 and see if it makes any difference?

In the meantime, I'm working on tracking down HW to try to reproduce this.

[lintweaker]

Originally Posted by Stephen Warren

It looks like you're using driver 195.36.31. There have been a number of changes related to audio-over-HDMI since then. Can you please try driver 256.35 and see if it makes any difference?

In the meantime, I'm working on tracking down HW to try to reproduce this.

Thanks, I hope you can (reproduce the problem and) fix it when you get the HW.

I did initially start with 256.35 but had some issues with tearing so a went back to 195 series (with which I still get some tearing but that is another issue). I retested with 256.35, unfortunately this does not improve the situation, still no audio from HDMI. I've added a nvidia bug report for good measure.

If you need more info or other tests performed...

[Stephen Warren]

Apparently, the NVIDIA ALSA developers are aware of this issue. I'll try to drive them to find a solution.

In the mean-time, you can hack around this by patching the ALSA driver source code; the following is apparently against ALSA 1.0.23:

--- patch_hdmi.c 2010-07-20 15:55:50.274867526 +0800
+++ patch_hdmi.c-new 2010-07-20 15:57:13.474861844 +0800
@@ -635,7 +635,7 @@
spec->sink_eld[index].monitor_present = pind;
spec->sink_eld[index].eld_valid = eldv;

- if (pind && eldv) {
+ if (eldv) {
spec->sink_eld[index].monitor_present = 1;
hdmi_get_show_eld(codec, spec->pin[index],
&spec->sink_eld[index]);

[lintweaker]

Originally Posted by Stephen Warren

Apparently, the NVIDIA ALSA developers are aware of this issue. I'll try to drive them to find a solution.

In the mean-time, you can hack around this by patching the ALSA driver source code; the following is apparently against ALSA 1.0.23:

--- patch_hdmi.c 2010-07-20 15:55:50.274867526 +0800
+++ patch_hdmi.c-new 2010-07-20 15:57:13.474861844 +0800
@@ -635,7 +635,7 @@
spec->sink_eld[index].monitor_present = pind;
spec->sink_eld[index].eld_valid = eldv;

- if (pind && eldv) {
+ if (eldv) {
spec->sink_eld[index].monitor_present = 1;
hdmi_get_show_eld(codec, spec->pin[index],
&spec->sink_eld[index]);

OK, nice. I'll see if I can cook up a custom kernel with this patch. Fingers crossed that it will fix the problem (really minor patch ).

[lintweaker]

OK, with a patched kernel I got a bit further. With only a TV connected and with TV and receiver both connected they get properly detected.
Unfortunately I can only get distorted sound from my TV and from my receiver. Unplugging and re-inserting of the HDMI cable to not get detected. I guess the workaround can only get me so far.

Output from /proc/asound/card0/eld#5.0 (with both receiver and TV connected):

[root@macmini2010 card0]# more eld#5.0 
monitor_present		1
eld_valid		1
monitor_name		Panasonic-TV
connection_type		HDMI
eld_version		[0x2] CEA-861D or below
edid_version		[0x3] CEA-861-B, C or D
manufacture_id		0xa934
product_id		0xa0a6
port_id			0x20000
support_hdcp		0
support_ai		0
audio_sync_delay	0
speakers		[0x5f] FL/FR LFE FC RL/RR RC RLC/RRC
sad_count		8
sad0_coding_type	[0x1] LPCM
sad0_channels		2
sad0_rates		[0x1ee0] 44100 48000 88200 176400 192000 384000
sad0_bits		[0xe0000] 16 20 24
sad1_coding_type	[0x1] LPCM
sad1_channels		8
sad1_rates		[0x1ee0] 44100 48000 88200 176400 192000 384000
sad1_bits		[0xe0000] 16 20 24
sad2_coding_type	[0x2] AC-3
sad2_channels		6
sad2_rates		[0xe0] 44100 48000 88200
sad2_max_bitrate	640000
sad3_coding_type	[0x7] DTS
sad3_channels		7
sad3_rates		[0x6e0] 44100 48000 88200 176400 192000
sad3_max_bitrate	1536000
sad4_coding_type	[0x9] DSD (One Bit Audio)
sad4_channels		6
sad4_rates		[0x40] 48000
sad5_coding_type	[0xa] E-AC-3/DD+ (Dolby Digital Plus)
sad5_channels		8
sad5_rates		[0xc0] 48000 88200
sad6_coding_type	[0xc] MLP (Dolby TrueHD)
sad6_channels		8
sad6_rates		[0x1480] 88200 192000
sad7_coding_type	[0xb] DTS-HD
sad7_channels		8
sad7_rates		[0x1480] 88200 192000

Output from /proc/asound/card0/eld#5.0 (TV connected):

monitor_present		1
eld_valid		1
monitor_name		Panasonic-TV
connection_type		HDMI
eld_version		[0x2] CEA-861D or below
edid_version		[0x3] CEA-861-B, C or D
manufacture_id		0xa934
product_id		0xa0a6
port_id			0x20000
support_hdcp		0
support_ai		0
audio_sync_delay	0
speakers		[0x0]
sad_count		1
sad0_coding_type	[0x1] LPCM
sad0_channels		2
sad0_rates		[0xe0] 44100 48000 88200
sad0_bits		[0x20000] 16

Update: 23 July 2010:
Got everything working with the workaround ALSA patch. Both MythTV and mplayer happily play PCM, DTS, AC3 sound through the HDMI port. I noticed on the alsa-devel list there is a proper patch brewing so that's good news.

[Stephen Warren]

lintweaker, I only just noticed your update. Can you explain how you fixed the distorted sound? If you did something specific, write it here and maybe Google will find it to help other people:-)

Thanks.

[lintweaker]

Originally Posted by Stephen Warren

lintweaker, I only just noticed your update. Can you explain how you fixed the distorted sound? If you did something specific, write it here and maybe Google will find it to help other people:-)

Thanks.

No worries . I cannot really explain why and how the distorted sound was fixed. It seems that, with the workaround patch, I need to make sure both my receiver and TV are already switched on before starting up the mac mini otherwise I cannot get sound.

But the proper patch/solution is already in the current ALSA GIT/daily snapshots. I already created a patch and build a new kernel but have not tried it yet.

I've created a guide how to get HDMI working on the mini (as well as how to install Fedora 13 on the mini). It can be found here

I will report back when I have tried my new kernel with the proper ALSA patch.

[Stephen Warren]

lintweaker, couuld you point out which git repository has the fix checked in; I couldn't find it anywhere within http://git.alsa-project.org/.

I'm slightly surprised that your receiver/TV need to be powered on and connected before the system is is started. Can you double-check if they need to be plugged in before the system is powered on (doesn't make sense to me), or simply before X is started (which is readily explainable, since the EDID is probably read when X starts). Finally, I'm certainly interested in whether the official version of the fix makes any difference to this.

Thanks very much!

[lintweaker]

OK, it seems it was a bit premature for me to assume that the patch already made it to ALSA GIT. The updated patch_hdmi.c and patch_nvhdmi.c can be found in ALSA's Takashi Iwai daily alsa-driver snapshot: http://ftp.kernel.org/pub/linux/kernel/people/tiwai/alsa/alsa-driver/

Sorry about that.

I just tried booting the mini mac mini and switching on the receiver and my TV at a later time (the mini was just logged in to the desktop). With dmesg I saw the usual HDMI messages but now it found the receiver as connected device and not the TV. Checking /proc/asound/cards/card0/eld#5.0 shows it detected all the supported bit rates and audio encoding properly but I do not have sound.

The TV also thinks it's in 1080i / 60 Hz mode instead of 1080p / 50Hz. Checking Xorg.0.log reveals:

[ 25.974] (--) NVIDIA(0): Interlaced video modes are supported on this GPU
[ 25.974] (--) NVIDIA(0): Connected display device(s) on GeForce 320M at PCI:5:0:0:
[ 25.974] (--) NVIDIA(0): YMH RX-V1065 (DFP-1)
[ 25.974] (--) NVIDIA(0): YMH RX-V1065 (DFP-1): 165.0 MHz maximum pixel clock
[ 25.974] (--) NVIDIA(0): YMH RX-V1065 (DFP-1): Internal Single Link TMDS
[ 26.013] (II) NVIDIA(0): Assigned Display Device: DFP-1
[ 26.013] (II) NVIDIA(0): Validated modes:
[ 26.013] (II) NVIDIA(0): "pan1080p50"
[ 26.013] (II) NVIDIA(0): "pan1080p60"
[ 26.013] (II) NVIDIA(0): "pan1080p24"
[ 26.013] (II) NVIDIA(0): "pan720p50"
[ 26.013] (II) NVIDIA(0): "pan720p60"
[ 26.013] (II) NVIDIA(0): Virtual screen size determined to be 1920 x 1080
[ 26.052] (WW) NVIDIA(0): YMH RX-V1065 (DFP-1)'s EDID does not contain a maximum image
[ 26.052] (WW) NVIDIA(0): size; cannot compute DPI from YMH RX-V1065 (DFP-1)'s
[ 26.052] (WW) NVIDIA(0): EDID.
[ 26.052] (**) NVIDIA(0): DPI set to (101, 100); computed from "DisplaySize" Monitor
[ 26.052] (**) NVIDIA(0): section option
[ 26.052] (WW) NVIDIA(0): 32-bit ARGB GLX visuals require the Composite extension.
[ 26.052] (WW) NVIDIA(0): Disabling 32-bit ARGB GLX visuals.
[ 26.052] (--) Depth 24 pixmap format is 32 bpp
[ 26.052] (II) NVIDIA: Using 768.00 MB of virtual memory for indirect memory access.
[ 26.053] (II) NVIDIA(0): Initialized GPU GART.
[ 26.082] (II) NVIDIA(0): Setting mode "pan1080p50"

It seems it is important in which order I switch things on, but I can live with that.

BTW after removing the connection between the receiver and TV and plugging it back in things stay the same. I tried various combinations with the mac mini still on and switching off and on the receiver and / or TV. The receiver kept being listed a the connected device.