This a post for people who have a DisplayPort connection with functional video, but non-functioning audio from a connected monitor. The situation can be hardware or configuration, or a blend.
short overview
DisplayPort is HDMI quality video, a significant step-up from VGA, but without an audio channel. The output jack is a special shape, so we need an inexpensive adapter cable DisplayPort <--> HDMI. We then connect the HDMI end to any monitor's HDMI port.
DisplayPort does not have an audio channel. So we have to run sound separately using a 3.5mm output cable to connect sound to our monitor. However, even with a separate 3.5mm audio cable plugged in, users can experience the same "no audio" problems they do with an HDMI cable.
I've done other posts on HDMI cable ELD handshake for HDMI audio, and the steps are the same with DisplayPort. I'm repeating the steps here in a dedicated DisplayPort post, since it might be easier to Google search for those suffering through DisplayPort configuration.
helpful commands
Before anything else, a few helpful commands to hopefully avoid rebooting once configured. PulseAudio is killed and restarted with...
$ pulseaudio -k or --kill
$ pulseaudio -D
ALSA usually will reread alsa.conf and restart without a reboot:
# systemctl restart alsa-restore.service
most likely explanation - monitor limitation
Some monitors can't detect true HDMI apart from DisplayPort, since the cable connection is HDMI on the monitor end. The monitor assumes audio is incoming via the HDMI cable per usual. These types of monitors disable the 3.5mm audio input to prevent duplication. There's no way to achieve monitor sound in this circumstance. Users must test their computer's 3.5mm audio output with a set of speakers.
However, the scenario above is horribly underdocumented. Many people go crazy attempting to make the monitor produce sound from the connected 3.5mm input. Even more deceptively, these monitors usually have no 3.5mm audio problems as long as the video input is a VGA cable.
less likely -- ELD problems
Once we obtain ELD-related numbers, my easiest solution for ensuring ELD handshake is via /usr/share/alsa/alsa.conf customization. Updates to ALSA will overwrite our customization, but we can always repeat the steps if we encounter audio problems again.
I like info on how the computer is naming cards and so on, in case I have a long troubleshoot, but the most important step is using grep to verify ELD. Skip to that step below if desired.
Verify DisplayPort is connected to the HDMI port on the video monitor and receiving video. Next, how is the system ordering its analog PCH chip and HDMI digital chip? Simplest check:
$ cat /proc/asound/modules
0 snd_hda_intel
1 snd_hda_intel
... but in this case, we need more. We're only able to tell both chip 0 and 1 were manufactured by intel. So we...
$ cat /proc/asound/cards
0 [HDMI ]: HDA-Intel - HDA Intel HDMI
HDA Intel HDMI at 0xf7c32000 irq 39
1 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xf7c30000 irq 40
...ok the digital card is card 0 and the analog is card 1.
But we still don't which device on the card has handshaked. For that, aplay goes deeper and gives each device number on the cards.
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [E622VLE]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC3220 Analog [ALC3220 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
But I prefer to verify ELD is handshaking with device 3.
$ grep eld_valid /proc/asound/card0/eld*
/proc/asound/card0/eld#0.0:eld_valid 0
/proc/asound/card0/eld#0.1:eld_valid 0
/proc/asound/card0/eld#0.2:eld_valid 0
/proc/asound/card0/eld#0.3:eld_valid 1
/proc/asound/card0/eld#0.4:eld_valid 0
/proc/asound/card0/eld#0.5:eld_valid 0
With hw 0,3 confirmed, I carve this in stone in my /usr/share/alsa/alsa.conf file.
# nano /usr/share/alsa/alsa.conf
defaults.pcm.subdevice 3 # -1 is default
step 2 - restart and test
The easiest for me is to reboot, but others may want to restart alsa. Am I getting sound? If so, then I should also be able to normally test the connection this way.
$ aplay -D plughw:0,3 /usr/share/sounds/alsa/Front_Center.wav
There are other sounds, I just use Front_Center out of habit I suppose
