sound and systemd, restart sound

Running HDMI means dealing with two audio chips -- the first on the motherboard and a second on the video card, where the A/V HDMI cable is connected. Many things can therefore derail the sound. In this case it was an Arch update, causing some conflict with the kernel. But each failure has to be solved by a process of elimination. ALSA is embedded into the kernel, so that systemd is the way to restart.

# systemctl restart alsa.restore.service

Should d

Let's suppose the connected HDMI device at the other end of the cable is putting out clean video. Now let's suppose the audio is also present, but that it sounds distorted: chipmunky or maybe raspy or fuzzy, like a bad AM radio connection. We know that at least one of the audio chips IS working if sound is present at the output. But solving the distortion many not be easy. Perhaps the wrong sound chip, both chips simultaneously, or that the correct chip has incorrect settings. You've done everything here and the gold standard...

$ aplay -D plughw:1,7 /usr/share/sounds/alsa/Front_Center.wav

...for your particular hardware, which you correctly determined with...

$ aplay -l

Suppose this is in spite of Pulseaudio being effectively disabled , /usr/share/alsa/alsa.conf successfully sterilized of hooks, and /etc/asound.conf, ~/.asoundrc, and ~/.config/asound.conf having been successfully deleted.

Suppose also that we have...

$ systemctl list-unit-files |grep alsa
alsa-restore.service static
alsa-state.service static

$ systemctl list-units |grep sound
sys-devices-pci0000:00-0000:00:01.0-0000:01:00.1-sound-card1.device loaded active plugged GK104 HDMI Audio Controller
sys-devices-pci0000:00-0000:00:1b.0-sound-card0.device loaded active plugged 7 Series/C216 Chipset Family High Definition Audio Controller
sound.target loaded active active Sound Card

... well then WTF is going on? We can see ALSA is properly "static" and therefore compiled into the kernel. We can see that both hardwares examine some of those systemd service modules inside /etc/systemd/system/, but this does not seem to be the problem.

possibility 1

Suppose you still have an unaddressed situation of both sound cards receiving the same name from the kernel

$ cat /proc/asound/modules
0 snd_hda_intel
1 snd_hda_intel