Bug 92827

Summary: Tonga: No Sound over HDMI with connected AV receiver
Product: DRI Reporter: Maximilian Böhm <mabo>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: fdsfgs, mabo, marius, sonny, thesaxophonist
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
cat /proc/asound/card1/eld#0.0 none

Description Maximilian Böhm 2015-11-05 00:31:02 UTC
Created attachment 119417 [details]
cat /proc/asound/card1/eld#0.0

I'm using the new amdgpu driver on Linux 4.2 and 4.3 RC7 with my new Radeon R9 380.
I want to use my 5.1 receiver to get audio over HDMI, it works just fine under Windows 8.1. Under Manjaro Linux, I have configured a standard FullHD output on HDMI with 60 Hz – with my former Radeon HD 7770 using radeonsi this was the rule to get audio (don't get me started on broken HDMI audio on radeonsi. With Linux 4.0+ until now, I needed to use the 3.18 kernel to *not* see only "unplugged" outputs in PulseAudio. See bug 90777.).
In fortunate distinction to radeonsi on Linux 4.0+, PulseAudio shows 2.0, 5.1 and 7.1 output over HDMI as plugged in and available. But I don't get any output.
No HDMI audio output on Tonga using amdgpu on Linux 4.2 and 4.3 RC7.
Comment 1 Maximilian Böhm 2016-05-19 16:33:16 UTC
I can still confirm this bug with Linux 4.6.0. :(
Comment 2 Alex Deucher 2016-05-19 16:40:19 UTC
Audio support requires DAL which is not upstream yet.  E.g.,
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.7-wip-dal
Comment 3 Maximilian Böhm 2016-05-19 17:25:22 UTC
At least something to await for! Would be neat to put this info somewhere in a non-dev press release. I fiddled many hours with this issue without knowing anything about the state of HDMI audio on AMDGPU. There must be countless frustrated users, even more when you think of the Ubuntu 16.04 shift away from fglrx.
Comment 4 dwagner 2017-10-15 18:46:12 UTC
JFYI: HDMI audio output works fine with amdgpu as present in current https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
Comment 5 Michael Zapf 2017-11-24 17:12:10 UTC
I just got kernel 4.14, but I still don't have any audio output via HDMI. Is that supposed to work by now?
Comment 6 Maximilian Böhm 2017-11-24 19:28:33 UTC
No, it will be merged with Linux 4.15 but you will still need an kernel parameter: https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-Accepted
Until then, you have to compile yourself a patched kernel. For Arch-based distros you can use the AUR linux-amd-staging-drm-next-git. Phoronix provides pre-compiled packages for Ubuntu.
Comment 7 Michael Zapf 2018-02-04 15:28:15 UTC
With 4.15 (and the kernel boot parameter!) I now managed to get audio output via HDMI. 

Splendid!

My configuration is 

PC ----HDMI---> Pioneer AV receiver (vsx330) ---HDMI---> HP monitor (lp2475w)

But there is one bad effect now: When I turn off the monitor during runtime, or if the monitor enters power-save state, and it is turned on again, the screen resolution is reset to a maximum of 1368x768 (before: 1920x1200), which messes up the desktop.

The reason is that when the monitor is turned off, this seems to be sensed as a change in the HMDI connection, and the EDID data is now coming from the AV receiver. 

dmesg says:

[   82.689994] [drm] VSX-330: [Block 0] 
[   82.689995] [drm] VSX-330: [Block 1] 
[   82.689997] [drm] dc_link_detect: manufacturer_id = 2F41, product_id = 1027, serial_number = 1010101, manufacture_week = 0, manufacture_year = 25, display_name = VSX-330, speaker_flag = 79, audio_mode_count = 8
[   82.689998] [drm] dc_link_detect: mode number = 0, format_code = 1, channel_count = 1, sample_rate = 127, sample_size = 7
[   82.689999] [drm] dc_link_detect: mode number = 1, format_code = 1, channel_count = 7, sample_rate = 127, sample_size = 7
[   82.690000] [drm] dc_link_detect: mode number = 2, format_code = 2, channel_count = 5, sample_rate = 7, sample_size = 80
[   82.690000] [drm] dc_link_detect: mode number = 3, format_code = 7, channel_count = 6, sample_rate = 6, sample_size = 192
[   82.690001] [drm] dc_link_detect: mode number = 4, format_code = 9, channel_count = 1, sample_rate = 127, sample_size = 0
[   82.690002] [drm] dc_link_detect: mode number = 5, format_code = 10, channel_count = 7, sample_rate = 6, sample_size = 0
[   82.690002] [drm] dc_link_detect: mode number = 6, format_code = 11, channel_count = 7, sample_rate = 126, sample_size = 1
[   82.690003] [drm] dc_link_detect: mode number = 7, format_code = 12, channel_count = 7, sample_rate = 126, sample_size = 0
[   82.691002] Raw EDID:
[   82.691003]          c8 01 00 00 06 00 00 00 20 00 00 00 02 00 00 00
[   82.691003]          80 07 00 00 b0 04 00 00 01 00 0a 00 fc 05 e0 01
[   82.691004]          e0 04 00 00 00 00 00 00 01 00 01 00 00 00 02 00
[   82.691004]          00 00 00 00 00 0a 00 00 01 00 00 00 70 00 00 00
[   82.691004]          08 00 02 00 fc 05 e0 01 12 00 07 00 fc 05 e0 01
[   82.691005]          9b 01 00 00 04 00 00 00 20 00 00 00 01 00 00 00
[   82.691005]          04 00 00 00 01 00 0a 00 fd 05 e0 01 e0 04 00 00
[   82.691006]          00 00 00 00 1e 00 1e 00 00 00 02 00 00 00 00 00
[   82.691007] amdgpu 0000:01:00.0: HDMI-A-2: EDID invalid.

Note that the monitor is typically labeled as HDMI-A-1.

The screen configuration in KDE lists 1368x768 as the maximum resolution now. 

I managed to restore the old resolution either by rebooting, or by turning off the AV receiver, then turning it back on. Still, the desktop is messed up.
Comment 8 Alex Deucher 2018-02-04 19:27:45 UTC
I suspect the receiver manufacturer never validated DPMS.  Most consumer electronic devices (media players, DVD, Bluray, cable boxes, etc.) don't actually blank the display.
Comment 9 Christian König 2018-02-05 11:41:48 UTC
Yeah, that is a problem I still have with my AV-setup as well.

In general the fault is caused by the AV receiver not correctly implementing the EDID handling (the timing turning things on/off is usually not correctly validated/implemented).

We could do something like adding an option to re-query the EDID x seconds after an hot plug event and compare if it's changed.
Comment 10 Michael Zapf 2018-02-09 00:28:17 UTC
I now believe there is a general problem with amdgpu's new DC. 

On another system, without an AV receiver in the chain, my display resolution is reset to 1368x768 when I turn off the monitor and back on. That's a really mess (not only my desktop after that). I have to reboot to get the full resolution again; killing X or unplugging the monitor does not restore it.

Seems as if I have to turn off DC again and wait for a fix. <grmpf>

I have this issue in my office (RX460) and on my second PC (RX580), reproduceably, all running openSUSE Tumbleweed, 4.15.1.
Comment 11 Maximilian Böhm 2018-02-12 16:45:30 UTC
I feel your pain, I’m experiencing something similar here:
RX 580 → HDMI @ FullHD → Marantz NR1504 → [EDID-Fake-Plug]
RX 580 → DP @ UHD → Dell P2715Q.

Sometimes, when I turn the monitor off and on again, my desktop resolution is reduced to 2048x1536 (this is not even 16:9) and I have no other option than rebooting to get 3840x2160 again. This was new coming with the DC patches but does not happen every time I turn the monitor off and on again, rather rarely, but is endlessly annoying.
Comment 12 Harry Wentland 2018-02-12 20:17:37 UTC
Looks like the conversation steered away from audio. 

Please use a new ticket or comment on existing tickets dealing with wrong modes, such as https://bugs.freedesktop.org/show_bug.cgi?id=105046.
Comment 13 Martin Peres 2019-11-19 08:06:44 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/58.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.