Trying to get HDMI audio output. Reached the point where I can get HDMI audio devices to appear, however no audio comes out of the ports 99% of the time at system boot. Details below. On the extreme rare occasions that I get audio on HDMI, it disappears after a reboot (ditto power pulls) without making any changes. Hardware for reference is a J5005 NUC7 running the latest Intel BIOS (0062). > [ +0.000000] DMI: Intel(R) Client Systems NUC7PJYH/NUC7JYB, BIOS > JYGLKCPX.86A.0062.2021.0419.1701 04/19/2021 I am running Debian Buster with a kernel built from the release tarball of Linux 5.12.4 release. Built with `make bindeb-pkg` based on existing Debian kernel configuration, and installed the resulting kernel packages. Buster's 4.19 kernel only enumerates the analog port, so I first tried Debian's backports to upgrade to Linux 5.10 and pull in newer libasound/pulseaudio. Arrived at these details and then rechecked with a fresh build of Linux 5.12.4. On 5.12.4 and distro's 5.10, I see the same results. With no driver options: only analog audio devices are enumerated on 512.4 and 5.10. To get HDMI devices to appear, I need to set these snd-hda-intel driver options in my modprobe configuration: > options snd-hda-intel power_save=0 The power_save option has been required to get anything to appear on 5.12.4 and 5.10. On 5.10: I needed to to add enable_msi=1 or receive I get messages about no response form codec similar to #205229. Does not occur so often on 5.12.4. Likewise, need to configure xorg to use the Intel graphics driver to get HDMI audio. Leaving X.org to guess, I never saw HDMI audio working. At this point -- trying to play audio from user space results in no audio out the ports. speaker-test, video players, etc. Trying to look deeper, I notice that /proc/asound/card0/eld#2* shows no monitor/eld when the audio does not work. If I do "xrandr --output $port --set audio off" followed by "xrandr --output $port--set audio auto" for HDMI1 and HDMI2, on Linux 5.12.4 I get audio out of both ports and the eld* files show appropriate information for my HDMI displays. On 5.10, only HDMI2 actually responded with audio and only part of the time. In 5.12.4 the audio off / auto toggle at least seems to generate audio, but I don't unstand while the eld files do not update when hotplugging monitors after that. If I do the above xrandr, while the eld files show info for my monitors they never update. Unplug a monitor, file content is the same. Swap cables and the eld file does not update unless I do the xrandr command again, and only that port updates. At this point, I can reboot and audio may or may not play on the rebooted system. In most cases it will not. It seems like the first time I reboot, audio is working and the second time I reboot audio is not working. Been able to do that at least twice in a row. Maybe it is predictable.
Created attachment 296751 [details] Output from dmesg, alsa-info, etc tar file with alsa-info, dmesg, driver conf files, and head /proc/asound/card0/eld#2.* for both working / non working audio.
Kai, does it hit your radar?
Terry, this would seem like a i915 driver issue. You could dig up a bit more info by looking at the i915 driver side status. Instead of the ALSA eld procfs entries, you can look at the display information from i915 driver via: sudo cat /sys/kernel/debug/dri/0/i915_display_info If a monitor is found with audio support, something like following is included in the output: [CONNECTOR:255:HDMI-A-2]: status: connected physical dimensions: 480x270mm subpixel order: Unknown CEA rev: 3 audio support: yes HDCP version: HDCP1.4 If you attach a monitor with audio capability, it should be listed as such every time. If not, this smells of a bug in the hotplug functionality. Typical steps to debug i915 issues are to 1) try with latest drm-tip kernel (https://cgit.freedesktop.org/drm-tip), and 2) take DRM logs (add kernel parameters "drm.debug=0x1e and log_buf_len=4M" and attach the dmesg. The i915 bugs are tracked at https://gitlab.freedesktop.org/drm/intel/-/issues but typically the first thing asked is 1&2.
Hi, I may be experiencing the eld part of this bug. The H/W is of a similar generation, a NUC7i3BNH (NUC7i3BNB is the base board number). The BIOS is the most recent and the HDMI firmware has also been updated. However, contrary to bug reporter I'm using Arch Linux and the most recent Kernels it's having, at the moment I'm writing this I'm using the lts branch (5.15.21-1-lts) but I've had the exact same behaviour with the non-lts branch during the last few weeks. But I'm only having the eld problem. This means, I don't need to give the parameter to snd-hda-intel: > options snd-hda-intel power_save=0 Nor do I need to set enable_smi or configure X.org in any way, autodetection works fine. However, the part about the eld files not updating sounds very familiar, though. The eld files show: > monitor_present 0 > eld_valid 0 Despite having an audio-capable device at the corresponding port. When this happens, I do get audio after I run 'xrandr --set audio on', and if I do, eld nodes stop auto-updating (luckily I don't actually ever need to replug the HDMI cables, so this does work as a workaround for me). I have no idea how to enable audio (eld regeneration) without running X.org, in case I wanted to use the audio in a non-graphical environment. The HDMI output can not be enabled (AFAIK) in ALSA (and usbsequently PulseAudio) if the eld file shows eld_valid 0. Curiously, I still get graphics output despite monitor_present 0!. I've also noticed that /sys/class/drm/card0-DP-1/edid is very slow to update (up to tens of seconds) sometimes, and sometimes gets stuck and does *not* actually update if many replugs have been attempted, for any subsequent re-plugs. Only way (I've found) is to reboot if the driver is in this state. This problem is a bit difficult to reproduce, as it seems to happen randomly (I've ruled out HDMI cable issues by trying out many cables and trying the cables on different devices). This is just to let you know. If there has been / is any progress on this issue, I can try to reproduce and provide the aforementioned logs. Problem for me finding what is going on is that there is little documentation about the eld nodes and how/who/what part of the driver stack generates them, and no output in logs at default. However now I've found a good pointer now on how to go on!