KODI: can not find audio device [EDID->eld#X.X bug] [Workaround]

Wild Penguin · 2022-02-04 13:46:58

Hi,

I'm setting up a quite minimal / lean KODI box on an Intel NUC. The goal is that it will start KODI after powering on, as a user specifically reserved for running KODI, without any log in from a user.

I could not run kodi via lightdm nor nodm (as per the wiki) (see *; the failure is at the stage when kodi is run; the user is logged in, X.org can start). I did manage to run kodi automatically with sddm in the end.

However, kodi does not find any audio devices (the only one I have is the HDMI via the intel GPU on the NUC). I've also noticed I can not play any audio if I SSH into the NUC. I *can* play audio if I log in locally in to the NUC (as any user, not the "kodi" user). Kodi user can find audio device in case I log in locally and *then* start kodi.

Is pulseaudio working as intended? Should I add the user kodi (and possibly other who are not logged in locally, but use some remote service, say SSH) into the audio group and/or start system-wide?

EDIT: I.e. is my use case specifically / exactly and use case example, where I would need the audio group?

In case you are using kodi in a standalone setup (starts automatically), how have you done this specifically? Do you use the unit files from AUR?

I'm asking before updating wiki, in case it is an user error, so I will not enter faulty information there I haven't done any special setups, this is a really fresh installation.

Cheers!

p.s. Now, it seems the wiki kodi article is a bit out of date in addition to this audio problem:

1. I can not use LightDM nor nodm to start KODI. LightDM segfaults (which it should not do!) unless lightdm-autologin has been set up correctly (it should fail in a sensible error, instead, perhaps with a meaningful error message). After setting up autologin, I can see from logs that the user kodi is logged in, however KODI never starts. It seems that lightdm does try to start kodi, but this fails for some reason; however, there are no log files created for kodi. Seems like /var/lib/lightdm-data/kodi is created, however, with wrong permissions assuming usere 'kodi' is supposed to be able to browse into this directory. Nodm behaves in a similar way. My guess is, that they try to run kodi with some other home directory, besides /home/kodi, which has wrong permissions set up, but this is a pure guess since there is no sensible output from the kodi process which - I presume - does try to run for a split second. I can post lightdm and nodm logs, but they don't really provide any meaningful information.

2. /var/lib/kodi directory is not created for any of the standalone ways I've used. All use /home/kodi instead (it may be the /var/lib/kodi article is only referring to the unit files in AUR - which I've opted to not use so far, since I try to keep the system lean. I may use the AUR in case it makes using the system easier in the end.

The audio group information should definitely be added into the wiki in case it is needed. Any other suggestions

Last edited by Wild Penguin (2022-02-11 14:18:54)

Wild Penguin · 2022-02-05 19:22:51

Ok, it seems I was a bit on the wrong track because of multiple problems.

1st, I was correct on the assumption that one can not use PulseAudio if just SSHing into a box (and starting playback to be played back on the remote machine). That makes sense for most use cases. Adding the user to the audio group does enable audio playback. However, the auto logged in user does not need to be added to the audio group, and things work correctly on my end - but I was confused by another issue, which is purely HW related AFAIK! Which brings us to the:

2nd issue: I suspect my NUC (NUC7i3BNH) just has a buggy HDMI if used with audio output. There even is a firmware update for this series of NUCs. According to some online searches, seems like I'm not the only one having audio issues with NUC HDMI output; some have users have opted to use a USB-C adapter. What is even more problematic, is that the firmware can only be updated in Windows! Yay for great Linux support!

So, the only real issue is (this more pressing) HW problem - which, I can reproduce even on the latest Ubuntu and Arch LTS branch Kernel.

For the interested, a more precise description about the failure (and the source of confusion) follows: The issue is much more common if X.org is running and the resolution is 1080p (50 or 60Hz), but does happen even without X.org running. Usually audio starts to play back, but (this is the most peculiar thing!) - stops when 10 minutes have endured after the link HDMI audio was enabled, on the dot. Sometimes the HDMI connection fails to initialize audio output at all (<- this was confusing me, to think the kodi user needs some additional setup; turns out it didn't - autologin works just fine for Pulseaudio!).

From the OS side, the failure can manifest in various ways. Sometimes it seems like audio is output correctly at the HDMI sink, however, the audio amp receives no data (according to it's display, there is no audio data stream - I'm using a toslink audio extractor). But sometimes the ALSA audio device is in various kind of error states, which can be seen with alsa and pulseaudio tools (however, logs remain empty). I can remember two different kind of failures: Simplex modes are not available (no input, only output), however duplex (digital out + analog in) is but doesn't actually output anything; sometimes audio devices go missing and there is only (PulseAudio) dummy output (<- the confusing part if this happens straight at log in when trying to use audio!). Sometimes the HDMI link drops out audio, but sometimes also video (i.e. no image on the monitor). Sometimes re-plugging the HDMI enables audio to be output, but after around three failures, only way to get any audio is to power cycle the NUC (I haven't been able to get into a state where no video is shown; I haven't had the video dropped out if I haven't used audio).

I have tried several HDMI cables, and have also tried another device with the same cables (so they do work). Also, the very common 10 minute failure points towards a firmware (or software) issue.

I realize there is little log files here, but there really is nothing interesting there. System journal is empty when this happen. In the "worst" failure mode, when there are no audio devices present, even then there is nothing in the logs; not even in user (journalctl --user or journalctl -u pulseaudio). Seems like Pulseaudio is just happy with the audio device dropping out, and does not think that is an error!

In kodi.log I sometimes get this:

CGLContextEGL::SwapBuffers: last msc time greater than interval

But nothing else.

As a last resort / workaround, USB-C to DP/HDMI adapter should work for my use case!

TL;DR: This seems like a H/W defect, and one of the various failures confused me a bit. According to online searches, some intel NUCs seem to have audio / HDMI issues, which supposedly could be fixed with a Firmware upgrade; it is also possible the NUC unit I have is just broken. A peculiar thing worthy of note is that more often than not the failure happens after 10 minutes of audio use, on the dot! I will try to get the firmware upgraded, but that may take some time since it requires Windows (*sigh*). I will report back here!

Last edited by Wild Penguin (2022-02-05 19:23:41)

Wild Penguin · 2022-02-06 12:24:36

Ok, I think I've sorted out (most of) the audio problems. The trouble with troubleshooting this time was that there were several problems!

First, indeed there is something fishy with the Intel HDMI output. I did go trough the trouble of installing a trial Windows to upgrade the firmware. A hint in case you are in the same boat and need to do this: you also need to install the Intel GPU drivers and possibly chipset for the upgrade utility to be able to see the HDMI controller (my windows was offline all the time, so I intalled these manually). But the firmware upgrade did not help with this issue, it still persists: sometimes the audio output is initialized correctly, but sometimes is not; (i.e. either there is no ALSA audio sink for the HDMI, or it is there but does not actually work or output anything; this is reflected in pactl sink list and probably in ALSA; I haven't checked when the issue happens).

Then, I though about the 10 minute time. It seems quite odd to me (well, doesn't anymore!). I noticed it is not actually counted from the last time I started audio playback but from the last time I gave any input in KODI (X.org) - this just usually coincides with the start of audio playback, obviously since I use the input to start the audio while I was making tests. I checked and KODI did not have any power saving for the screen enabled. Well, then I though about some DPMS stuff, and lo and behold:

$ DISPLAY=:0 xset -q
Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  XKB indicators:
    00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
    03: Compose:     off    04: Kana:        off    05: Sleep:       off
    06: Suspend:     off    07: Mute:        off    08: Misc:        off
    09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
    12: Group 2:     off    13: Mouse Keys:  off
  auto repeat delay:  660    repeat rate:  25
  auto repeating keys:  00ffffffdffffbbf
                        fadfffefffedffff
                        9fffffffffffffff
                        fff7ffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  2/1    threshold:  4
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  600    cycle:  600
Colors:
  default colormap:  0x22    BlackPixel:  0x0    WhitePixel:  0xffffff
Font Path:
  /usr/share/fonts/100dpi,/usr/share/fonts/75dpi,built-ins
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Disabled

I believe X.org things no input = no activity; but curiously, if I play back a video in KODI, blanking does not seem to occur. The blank only triggers if I play only audio (despite there still is some minute activity on the screen, usually). Enabling a screensaver (showing something pretty but more active in KODI) seems to prevent screen blanking and the dropout for audio-only content! As a proper fix I will make a [serverflags] section.

There is still the problem that the audio device for the HDMI output is not always initialized when X.org (KODI) is run. While troubleshooting, I've tried to set some module parameters (as just a guess):

$ cat /etc/modprobe.d/i915.conf 
options i915 enable_guc=2 enable_dc=0

But these do not help with the audio sink initialization issue.

However, I can work around this, since if HDMI audio is not initialized correctly, just toggling the refresh rate usually gets some audio. This can become an annoyance in the long run, any tips are still welcome to get the HDMI output to initialize more reliably. The blanking issue was more of a problem, and not having that means the audio sink does not need to re-initialize all the time (save for refresh rate changes for different content).

TL;DR: In the end, this was a combination of buggy Intel HDMI Audio and X.org DPMS settings (also see next post!).

EDIT: minor clarifications and TYPOs added ;-)

Last edited by Wild Penguin (2022-02-06 13:25:13)

Wild Penguin · 2022-02-06 13:21:00

After a reboot, I noticed DPMS was activated:

DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is On

Not sure what had disabled it in the previous paste of xset -q output (I definitely had not done it myself!). Blanking should not interrupt the HDMI output but monitor standby/suspend definitely will.

But indeed adding the serverflags makes the display not drop off! And, obviously:

DPMS (Energy Star):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Enabled
  Monitor is On

I will update the KODI wiki a bit (about sddm and dpms notes). In case someone has idea about why lightdm and nodm can not run, they are welcome (but perhaps worthy of another thread to not make this one too messy... my endeavors and monologue on solving this audio issue may seem convoluted enough just buy itself!).

Last edited by Wild Penguin (2022-02-06 13:25:48)

Wild Penguin · 2022-02-11 14:06:17

Hi again!

Replying here since I've found something new. I believe I've finally sorted out what is happening and found a workaround - just sharing my findings since this could be helpful to someone else .

Anyways, there were several problems and false assumptions I've been making, which made troubleshooting this a bit complicated, and this monologue thread of mine seem a bit complicated. Jump to workaround/TL;DR part if you are not interested and want to see the solution only. However, that part does not explain the actual issue that well, and especially not the troubleshooting process! The process can be a good example of the importance of describing the problem in it's entirety while troubleshooting and perhaps somewhat educational.

Anyways, I'll try to summarise things here in this reply!

First, my setup:

Intel NUC7i3BNH (7th gen Kaby Lake with it's IGP)
Connected via an HDMI to a HDMI swich with audio extraction (more on this later, this is important!)
The HDMI switch is connected to a projector which does not have any audio capabilities in itself
The HDMI switch outputs audio (via toslink) to an audio amplifier (somewhat irrelevant; the switch does not case where the audio goes, and the OS or devices "see" only the switch)

(I realize now I didn't describe this previously in it's totality, and I should have; I thought it is not relevant!)

Now, the setup with the HDMI switch works with other devices, so I've ruled out broken cables etc.; however, I should have pointed out none of the other devices I've been using have a similar GPU nor they run any full blown Linux distribution.

Which brings me to the false assumption I've made:

I have a single problem with the HDMI audio (there was a DPMS problem, too)
This may be an ALSA or PulseAudio problem (it isn't; it may be an GPU driver problem!)
The failure mode is a single kind and simple (it isn't!)

The other devices (which work) include the following:

SteamLink
ChromeCast
An Odroid C1 running LibreElec

Seems that none of the above devices care (that much) about the EDID and work just fine with the EDID data the switch provides in "pass" mode! However, the Intel NUC behaves a bit differently if the switch is in the "pass" mode! The switch has three modes: "pass"(trough)<->2ch<->5.1ch.

Now, that is a mouthful / many eyeful of text to digest, I know!

Now, to the actual problems I've determined I have/had

... and it seems there are four! These explain all the behavior I've been seeing:

Per default, the way I've been running KODI trough sddm, causes it to have DPMI active with a 10 minute delay
The Kaby Lake IGP has problems / slowness with receiving correct EDID information sometimes (seemingly randomly)
Something in the EDID -> ALSA driver -> generating eld chain sometimes fails (not sure why, I presume since EDID retrieval is slow)
If my HDMI swicth is in "pass" mode, there seem to be problems more often - up to seemingly it not working at all; however it seems the "pass" mode still works!

(sigh). Now I believe everyone reading can see why this was a bit difficult to crack! I'll try to go trough these problems one by one, and why exactly I think they are the problems I'm, having.

1. First, the DPMI problem. I think I've gone trough this in the thread previously. What confused me was that sometimes audio didn't work at boot / reconnecting the switch via HDMI, and sometimes it disconnected after 10 minutes of inactivity. I though the underlying cause was the same, which was false: the audio dropping out at 10 minutes had nothing to do with the other part of the problem. What confused me more was how I was testing the audio output: sometimes while testingI had the projector turned off (I use KODI often for audio-only content); so I didn't see the reason was that actually the DPMI power saving kicks in and shuts off the whole display. Setting timeout to zero disables this problem; one could argue this is a user error, or that KODI should disable DPMI, or that DPMI should not kick in if audio is being played back trough the port where the display is connected; however I can see that at least the last point is debateable!

2. Sometimes after re-connecting the HDMI cable (or toggling the audio mode switch on the HDMI switch between pass <-> 2ch <-> 5.1ch - these are equivalent according to my tests) the IGP i915 driver EDID reading will be in a stuck state! It will not generate any /sys/class/drm/card0-DP-1/edid at all (reading edid will read back empty); sometimes it will be "stuck" on the last edid it got, sometimes getting an edid will be possible only after a long delay (tens of seconds up to minutes; this is a bit difficult to take time of, since it is not reflected in any log, such as the system journal; X.org log may be the best logger for this!). Despite EDID not having updated, the display (projector) still shows a picture - so, you can probably see why the EDID data being stuck was one source of confusion for me! Note: on my system the connector name is indeed DP-1 instead of HDMI-1 (despite the port actually being and HDMI port; perhaps it is internally a DP but only the physical port is an HDMI port - i.e. there is an integrated converter here?)

3. Possibly because of the delay, sometimes there will be no proper /proc/asound/card0/eld#2.0. The file reads like this if it has been generated properly:

monitor_present         1
eld_valid               1
monitor_name            EPSON PJ
connection_type         DisplayPort
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0xa34c
product_id              0xa50e
port_id                 0x0
support_hdcp            0
support_ai              1
audio_sync_delay        0
speakers                [0x1] FL/FR
sad_count               4
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0x1ee0] 32000 44100 48000 88200 96000 176400 192000
sad0_bits               [0xe0000] 16 20 24
sad1_coding_type        [0x2] AC-3
sad1_channels           2
sad1_rates              [0x1ee0] 32000 44100 48000 88200 96000 176400 192000
sad1_max_bitrate        56000
sad2_coding_type        [0x4] MP3
sad2_channels           2
sad2_rates              [0x1ee0] 32000 44100 48000 88200 96000 176400 192000
sad2_max_bitrate        56000
sad3_coding_type        [0x7] DTS
sad3_channels           2
sad3_rates              [0x1ee0] 32000 44100 48000 88200 96000 176400 192000
sad3_max_bitrate        56000

And, like this if it has detected invalid eld:

monitor_present         0
eld_valid               0

(Note: despite indeed getting an eld node with "monitor_present 0" I still get video output!)

4. If the audio mode switch in the HDMI switch is in "PASS" position, the EDID data seems to report "no audio" capabilities. I.e. edid-decode includes (only) this section referring to audio:

    Audio latency: Audio not supported
    Interlaced video latency: 123 ms
    Interlaced audio latency: Audio not supported

But for 2 channel mode, the switch patches the EDID data:

  Audio Data Block:
    Linear PCM:
      Max channels: 2
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Supported sample sizes (bits): 24 20 16
    AC-3:
      Max channels: 2
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Maximum bit rate: 56 kb/s
    MPEG 1 Layer 3 (MP3):
      Max channels: 2
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Maximum bit rate: 56 kb/s
    DTS:
      Max channels: 2
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Maximum bit rate: 56 kb/s

and for 5 channel mode:

  Audio Data Block:
    Linear PCM:
      Max channels: 6
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Supported sample sizes (bits): 24 20 16
    AC-3:
      Max channels: 6
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Maximum bit rate: 56 kb/s
    MPEG 1 Layer 3 (MP3):
      Max channels: 6
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Maximum bit rate: 56 kb/s
    DTS:
      Max channels: 6
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Maximum bit rate: 56 kb/s

Now, it seems that ALSA (I've reproduced the audio problems without PulseAudio) does not enable HDMI output if the eld node says invalid eld. The breakage happens when this file does not advertise any audio. For one reason or another, the NUC (or Kaby Lake IGP driver, or snd_intel_hda) does not like the "pass" mode! It will be slower to retrieve the EDID and more often generates and invalid eld file than with other modes. However, it seems ALSA is happy if I trigger a regeneration of the eld file (with xrandr). In the "pass" mode of the switch (with no-audio EDID), I can still get this valid eld:

$ dog eld#2.0 
monitor_present         1
eld_valid               1
monitor_name            EPSON PJ
connection_type         DisplayPort
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0xa34c
product_id              0xa50e
port_id                 0x0
support_hdcp            0
support_ai              1
audio_sync_delay        0
speakers                [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH
sad_count               0

And ALSA has no problems with that!

Moreover, I got inconsistent results on the NUC since sometimes EDID reading gets "stuck"; for example, EDID reports 5 channels (despite the switch being in "pass" position). After a lot of trial & error I noticed, that sometimes the i915 driver will be in a state I just can not get it to report a new EDID - despite replugging the HDMI cable! In this case, only thing which helps is a reboot. However, now that I've found a proper workaround, multiple reconnections of the physical HDMI cable are not needed; which means, I will (hopefully) face non-EDID situation very seldomly.

Either way, if eld file which reports invalid eld, ALSA disables HDMI output - and in the end, this was the culprit of the problem. This problem does not report any errors in any logs!

Summary of this summary:.

In the end, there was the DPMS problem and the EDID -> eld problem. ALSA and PulseAudio work correctly in principle - and, in their eyes, nothing ever was wrong. In case eld is invalid -> ALSA does not see anything where audio could be output to! More importantly: No error logs, since all parts think there is no error! (I believe Kernel should be reporting an error by i914 or snd_hda_intel, but it doesn't; in the end I believe there is either a bug in the IGP driver, in ALSA driver or both).

I can "seemingly" output via PulseAudio to the HDMI, but if I look more closely, PulseAudio will report the output as "Suspended" and it can not be resumed. I believe this only happens if PulseAudio has seen an HDMI audio capable output at some point during it's runtime (this has happened only because I had the DPMI problem, and re-plugged the cable / used the HDMI switch without any display actually on!); if it has not seen any, it will only create the dummy device.

TL;DR / Workaround:

One way or another, the eld file needs to be generated properly with valid eld. In my case, booting the NUC with the HDMI switch in non-pass mode enabled audio trough the HDMI, but it does not work always (maybe 80-90% of the cases this creates a valid ELD at boot time!). If I have put the hdmi switch in the "pass" mode, I have more often the problem of an invalid eld; however, even the switch in pass mode gives an audio capable EDID and actually works with the following workaround!. If you have an invalid eld (in /proc/asound/cardX/eld* corresponding to your DP/HDMI output), then you may have the same problem, and the xrandr command may work.

1. If the EDID has been red, but eld still reports as invalid, try running:

xrandr --output DP0 --set audio on

This seems to regenerate the eld#2.X properly (prepend the xrandr with the correct DISPLAY=:0 variable, if you are not running from the X.org session).

2. In case EDID can not be red, then I believe only a reboot helps (however, this should be a rare case, since I know the xrandr trick and only needed, if the i915 can not get a proper EDID).

I believe I can create an automatic script to look ad the eld, and if it incorrect, re-generate it as valid.

There may be an i915 or snd_hda_intel bug in the background here I coulud probably report.

As for the DPMS: my ServerFlags section is a straight copy from the Wiki (all times set to "0"; I did not disable DPMS).

Cheers!

p.s. The best documentation for the eld I've found is here. I'm not sure what support_ai means, I suppose it means supports audio interface.

p.s.s. In case someone comes here by a search: When looking for a solution to my problem, I've seen users with similar audio problems. But in many cases it was caused by EDID data which does actually not have any audio capabilities; usually because their display H/W just reports broken EDID, or because they are using HDMI switches / audio extractors which do not patch the EDID properly. Those kinds of extractors are quite useless, of course, since the reason the user uses one is more often than not exactly because the display can not produce audio or can not produce it well enough (bad speakers, not outputs etc.), and an A/V receiver is not available / applicable in the use case. You may need to "lie" about the EDID to the kernel at boot time in this kind of situation; see drm.edid_firmware Kernel parameter or this stackexhange question as an example (I haven't tried this, since in my case this is not actually the problem).

EDIT: Emphasis. A few TYPOs.

Last edited by Wild Penguin (2022-02-11 14:21:10)

Arch Linux

#1 2022-02-04 13:46:58

KODI: can not find audio device [EDID->eld#X.X bug] [Workaround]

#2 2022-02-05 19:22:51

Re: KODI: can not find audio device [EDID->eld#X.X bug] [Workaround]

#3 2022-02-06 12:24:36

Re: KODI: can not find audio device [EDID->eld#X.X bug] [Workaround]

#4 2022-02-06 13:21:00

Re: KODI: can not find audio device [EDID->eld#X.X bug] [Workaround]

#5 2022-02-11 14:06:17

Re: KODI: can not find audio device [EDID->eld#X.X bug] [Workaround]

Board footer