radeon - HDMI Audio now unusable - unfinished business - radeon_audio_component_get_eld()

Arch Linux
alsa-lib 1.2.4-3
07:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series]

On boot, the radeon driver now fails to properly generate the the ELD data from the hdmi connected audio device. As a consequence, the hdmi audio can not function.

Recently, there has been some change in the Linux system that breaks hdmi audio in the radeon driver. This change does not appear to be directly connected with the kernel, libdrm, or alsa-lib, since reverting any of the these packages does not resolve the issue. Nonetheless, we may note that there are four commits in the kernel to drivers/gpu/drm/radeon/radeon_audio.c, dated 2020-11-16, which might suggest some connection.

As I understand, the radeon driver, unlike more recent ATI/AMD drivers, still relies upon the legacy HD-audio unsolicited event handling. In a directly related process, beginning 2019-07-22, a patch to the radeon driver was submitted to provide the radeon driver with more robust support for HDMI/DP audio notification via the drm_audio_component framework. This patch from Takashi Iwai appears to have been Acked-by Jim Qu and by Alex Deucher, but never actually forwarded downstream, and incorporated into the kernel drivers.

Please review this patch and the associated discussion beginning here: https://lore.kernel.org/dri-devel/20190722143815.7339-1-tiwai@suse.de/

Now that radeon hdmi audio is quite broken, it seems a good time time to resolve this issue with ELD notification in the ALSA.

Here are some additional symptoms which may help to inform whatever recent change has occurred, perhaps with the radeon driver itself, or with some other element of the ALSA.

There is some "mystery event" which is eventually able to trigger an Unsolicited Response ELD update, such that the update is recorded in "/proc/asound/card1/eld#0.0". It is unclear, based upon research and differences of opinion, whether or not the radeon driver hdmi audio should or should not be able to function prior to starting the Xorg server. For the sake of discussion, the issue described here presumes that Xorg is already running.

Immediately after boot, the file /proc/asound/card1/eld#0.0 contains only:

monitor_present         0
eld_valid               0

Ironically, it may be noted that, despite "monitor_present 0", there is a monitor present and displaying an image, even though the ALSA driver has not been properly informed.

But then, seemingly randomly, in response to some mystery event, an ELD update may be triggered, so that hdmi audio will begin to operate normally, and this same file will then show:

monitor_present         1
eld_valid               1
monitor_name
connection_type         HDMI
eld_version             [0x2] CEA-861D or below
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                [0x1] FL/FR
sad_count               4
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0xe0] 32000 44100 48000
sad0_bits               [0xe0000] 16 20 24
sad1_coding_type        [0x2] AC-3
sad1_channels           6
sad1_rates              [0xe0] 32000 44100 48000
sad1_max_bitrate        640000
sad2_coding_type        [0xa] E-AC-3/DD+ (Dolby Digital Plus)
sad2_channels           8
sad2_rates              [0xe0] 32000 44100 48000
sad3_coding_type        [0xc] MLP (Dolby TrueHD)
sad3_channels           8
sad3_rates              [0x80] 48000

There is another symptom, with a tragically amusing character, that may help inform the cause of this hdmi audio failure. It is possible, using xrandr, to set the "audio" parameter in the radeon driver, setting this "off", "on", or "auto". I have discovered that, after whatever mystery ELD event has enabled hdmi audio, when hdmi audio is working, that running xrandr --output DVI-0 --set audio off will disable the video display! However, setting the audio "on" again does not enable the video again. In this state, the hdmi audio will also stop working, even though the eld#0.0 file still shows "eld_valid 1", etc.

To add to the mystery, some random event is able to re-enable the display and the hdmi audio, perhaps in the same way that the hdmi audio alone is being mysteriously enabled. I have not found any method that reliably triggers hdmi audio, or restores the video, but it appears that starting an audio application, such as aplay, is sometimes associated with hdmi audio beginning to work. Unplugging and replugging the hdmi display device has no effect.

It seems possible that whatever process normally generates this ELD and passes the data to ALSA is now not being triggered properly or consistently. In which case there seem to be two alternative solutions. The first possibility is to revert whatever change is now causing the legacy ELD handling to fail. The second possibility is to implement the proposed "radeon_audio_component_get_eld()" mechanism, which should simplify and unify ELD handling in the radeon driver.