Realtek ALC1220 audio chipset on Linux Mint 18.1

Question

I just assembled myself a new computer with a quite new motherboard supporting an Intel Kaby Lake processor. This motherboard has a Realtek ALC1220 (S1220A) chipset for audio. After installing Linux Mint 18.1, I unfortunately noticed that the sound is not working. No soundcard is detected at all, whatever I try. The sound configuration just shows a Dummy Device.

user@linux-mint ~ $ aplay -l
   aplay: device_list:268: no soundcards found...

user@linux-mint ~ $ lspci -knn | grep -i -A4 Audio
   00:1f.3 Audio device [0403]: Intel Corporation Device [8086:a2f0]
   Subsystem: ASUSTeK Computer Inc. Device [1043:8723]
   Kernel driver in use: snd_hda_intel
   Kernel modules: snd_hda_intel
   00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:a2a3]

Motherboard: Asus ROG STRIX H270I GAMING
Audio Chipset: ROG SupremeFX 8-Channel High Definition Audio CODEC S1220A
Linux Distro: Linux Mint 18.1
Current Kernel: 4.11.6

What have I tried?

According to https://bbs.archlinux.org/viewtopic.php?id=226579 and Realtek S1220A under Linux Mint 18.1 support for the S1220A chipset was introduced in Linux Kernel 4.11. Linux Mint 18.1 ships with kernel 4.4, but has the option to upgrade to kernel 4.9 through the Update Manager. However, doing so and afterwards reinstalling all the ALSA stuff had no effect, still no audio device detected. Then I decided to install kernel 4.11.6 using UKUU. The installation seems to be completed without errors, and after upgrading GRUB my system boots Mint with the new kernel:

user@linux-mint ~ $ uname -r
   4.11.6-041106-generic

There are also reports of people who got the ALC1220 audio chipset working on kernel 4.9.

I have also founds some hints that it could be related to UEFI settings. Being a non-expert on this, I tried disabling UEFI and compatibility / legacy settings before booting my system, however none of this seems to have any effect.

Does someone have any clue how I can get sound on Linux Mint with this chipset?

Update 1:

dmesg | grep snd returns the following:

[    4.951807] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[    4.951966] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    5.079301] snd_hda_intel 0000:00:1f.3: CORB reset timeout#1, CORBRP = 0
[    5.080811] snd_hda_intel 0000:00:1f.3: no codecs found!

Update 2:

Following up on @dirkt advise to check the probe_mask, I have tried:

sudo modprobe -r snd_hda_intel
sudo modprobe snd_hda_intel probe_mask=0x1ff

Then checking dmesg it does not look like something changes:

[  374.653091] snd_hda_intel 0000:00:1f.3: codec_mask forced to 0xff
[  374.653126] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[  374.763149] snd_hda_intel 0000:00:1f.3: CORB reset timeout#1, CORBRP = 0
[  374.764764] snd_hda_intel 0000:00:1f.3: no codecs found!

Answer 1

Partial answer:

I looked at the ALC 1220 patch, and it just adds the same fixup as for the ALC 882 (which is used by quite a number of codecs).

But your problem seems to be that the communication with the Codec chip doesn't work at all. The soundcard driver snd_hda_intel loads, gets a single timeout error, but not the second one, so something works, but then it can't find any codec. So it never reaches the stage where the patch would be relevant.

Ideas:

1) Look in the BIOS if there are any settings for the soundcard. Maybe changing something here will make codec communication work.

2) The HD-Audio.txt says you can force probing if the BIOS is broken:

On a machine with a broken BIOS, sometimes you need to force the driver to probe the codec slots the hardware doesn't report for use. In such a case, turn the bit 8 (0x100) of probe_mask option on. Then the rest 8 bits are passed as the codec slots to probe unconditionally. For example, probe_mask=0x103 will force to probe the codec slots 0 and 1 no matter what the hardware reports.

So try as root

modprobe -r snd_hda_intel
modprobe snd_hda_intel probe_mask=0x1ff

and see what happens in dmesg.

3) If nothing helps, file a bug with the ALSA developers and see if they have any idea.

Answer 2

I managed to fix this issue for my setup.

I have the same chipset and after several hours going round in circles (I applied the realtek patch, forced the alsa drivers to restart etc as mentioned elsewhere etc. etc.) I eventually managed to get my sound working.

I used alsamixer via the following terminal command:

alsamixer

Press F6 to select 'HD Audio Generic' (or whichever option corresponds to your realtek chip).

After checking that none of the inputs were muted (indicated by MM and adjusted by pressing the 'M' key), I eventually toggled 'AutoMute' Enabled to Disabled using the down arrow key. Suddenly I had Foo Fighters blasting out of my speakers.