Realtek ALC1220 audio chipset on Linux Mint 18.1












1














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!









share|improve this question
















bumped to the homepage by Community 2 days ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.















  • What happens when you sudo modprobe snd_hda_codec_realtek? Anything in dmesg when snd_hda_intel probes for codecs? What does ls /proc/asound/card0/ show? Any codecs?
    – dirkt
    Jun 27 '17 at 22:32










  • The modprobe of snd_hda_codec_realtek doesn't do anything as far as I can tell, no output and no changes to my sound configuration. dmesg reports some error about codecs (added to the original post). And ls /proc/asound/card0/ returns no output.
    – verified.human
    Jun 28 '17 at 7:14


















1














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!









share|improve this question
















bumped to the homepage by Community 2 days ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.















  • What happens when you sudo modprobe snd_hda_codec_realtek? Anything in dmesg when snd_hda_intel probes for codecs? What does ls /proc/asound/card0/ show? Any codecs?
    – dirkt
    Jun 27 '17 at 22:32










  • The modprobe of snd_hda_codec_realtek doesn't do anything as far as I can tell, no output and no changes to my sound configuration. dmesg reports some error about codecs (added to the original post). And ls /proc/asound/card0/ returns no output.
    – verified.human
    Jun 28 '17 at 7:14
















1












1








1


1





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!









share|improve this 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!






linux-mint kernel audio realtek






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jun 28 '17 at 12:50







verified.human

















asked Jun 27 '17 at 21:54









verified.humanverified.human

11614




11614





bumped to the homepage by Community 2 days ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







bumped to the homepage by Community 2 days ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.














  • What happens when you sudo modprobe snd_hda_codec_realtek? Anything in dmesg when snd_hda_intel probes for codecs? What does ls /proc/asound/card0/ show? Any codecs?
    – dirkt
    Jun 27 '17 at 22:32










  • The modprobe of snd_hda_codec_realtek doesn't do anything as far as I can tell, no output and no changes to my sound configuration. dmesg reports some error about codecs (added to the original post). And ls /proc/asound/card0/ returns no output.
    – verified.human
    Jun 28 '17 at 7:14




















  • What happens when you sudo modprobe snd_hda_codec_realtek? Anything in dmesg when snd_hda_intel probes for codecs? What does ls /proc/asound/card0/ show? Any codecs?
    – dirkt
    Jun 27 '17 at 22:32










  • The modprobe of snd_hda_codec_realtek doesn't do anything as far as I can tell, no output and no changes to my sound configuration. dmesg reports some error about codecs (added to the original post). And ls /proc/asound/card0/ returns no output.
    – verified.human
    Jun 28 '17 at 7:14


















What happens when you sudo modprobe snd_hda_codec_realtek? Anything in dmesg when snd_hda_intel probes for codecs? What does ls /proc/asound/card0/ show? Any codecs?
– dirkt
Jun 27 '17 at 22:32




What happens when you sudo modprobe snd_hda_codec_realtek? Anything in dmesg when snd_hda_intel probes for codecs? What does ls /proc/asound/card0/ show? Any codecs?
– dirkt
Jun 27 '17 at 22:32












The modprobe of snd_hda_codec_realtek doesn't do anything as far as I can tell, no output and no changes to my sound configuration. dmesg reports some error about codecs (added to the original post). And ls /proc/asound/card0/ returns no output.
– verified.human
Jun 28 '17 at 7:14






The modprobe of snd_hda_codec_realtek doesn't do anything as far as I can tell, no output and no changes to my sound configuration. dmesg reports some error about codecs (added to the original post). And ls /proc/asound/card0/ returns no output.
– verified.human
Jun 28 '17 at 7:14












2 Answers
2






active

oldest

votes


















0














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.






share|improve this answer





















  • Thanks again for your very helpful comment. I've tried the things you suggest (see second update in first post), but unfortunately no luck. Here are 3 screenshots of my BIOS/UEFI settings that might be relevant, I've tried changing some things but also no luck. imgur.com/a/Z3Dt0
    – verified.human
    Jun 28 '17 at 13:04










  • What are the options under "HDA audio controller" and "Depop"? Just enabled/disabled? Try disabling "Depop". If you disable "HDA audio controller", does the lspci output change?
    – dirkt
    Jun 28 '17 at 14:32










  • Tried disabling both options in the Bios, but no changes. Still no soundscards detected :-(
    – verified.human
    Jun 29 '17 at 17:42










  • I'm out of ideas. Try filing a bug with the ALSA developers. If they find a solution, don't forget to update this question with your answer.
    – dirkt
    Jun 29 '17 at 17:53



















0














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.



Hope this helps someone.






share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f373777%2frealtek-alc1220-audio-chipset-on-linux-mint-18-1%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    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.






    share|improve this answer





















    • Thanks again for your very helpful comment. I've tried the things you suggest (see second update in first post), but unfortunately no luck. Here are 3 screenshots of my BIOS/UEFI settings that might be relevant, I've tried changing some things but also no luck. imgur.com/a/Z3Dt0
      – verified.human
      Jun 28 '17 at 13:04










    • What are the options under "HDA audio controller" and "Depop"? Just enabled/disabled? Try disabling "Depop". If you disable "HDA audio controller", does the lspci output change?
      – dirkt
      Jun 28 '17 at 14:32










    • Tried disabling both options in the Bios, but no changes. Still no soundscards detected :-(
      – verified.human
      Jun 29 '17 at 17:42










    • I'm out of ideas. Try filing a bug with the ALSA developers. If they find a solution, don't forget to update this question with your answer.
      – dirkt
      Jun 29 '17 at 17:53
















    0














    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.






    share|improve this answer





















    • Thanks again for your very helpful comment. I've tried the things you suggest (see second update in first post), but unfortunately no luck. Here are 3 screenshots of my BIOS/UEFI settings that might be relevant, I've tried changing some things but also no luck. imgur.com/a/Z3Dt0
      – verified.human
      Jun 28 '17 at 13:04










    • What are the options under "HDA audio controller" and "Depop"? Just enabled/disabled? Try disabling "Depop". If you disable "HDA audio controller", does the lspci output change?
      – dirkt
      Jun 28 '17 at 14:32










    • Tried disabling both options in the Bios, but no changes. Still no soundscards detected :-(
      – verified.human
      Jun 29 '17 at 17:42










    • I'm out of ideas. Try filing a bug with the ALSA developers. If they find a solution, don't forget to update this question with your answer.
      – dirkt
      Jun 29 '17 at 17:53














    0












    0








    0






    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.






    share|improve this answer












    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jun 28 '17 at 7:51









    dirktdirkt

    16.7k21336




    16.7k21336












    • Thanks again for your very helpful comment. I've tried the things you suggest (see second update in first post), but unfortunately no luck. Here are 3 screenshots of my BIOS/UEFI settings that might be relevant, I've tried changing some things but also no luck. imgur.com/a/Z3Dt0
      – verified.human
      Jun 28 '17 at 13:04










    • What are the options under "HDA audio controller" and "Depop"? Just enabled/disabled? Try disabling "Depop". If you disable "HDA audio controller", does the lspci output change?
      – dirkt
      Jun 28 '17 at 14:32










    • Tried disabling both options in the Bios, but no changes. Still no soundscards detected :-(
      – verified.human
      Jun 29 '17 at 17:42










    • I'm out of ideas. Try filing a bug with the ALSA developers. If they find a solution, don't forget to update this question with your answer.
      – dirkt
      Jun 29 '17 at 17:53


















    • Thanks again for your very helpful comment. I've tried the things you suggest (see second update in first post), but unfortunately no luck. Here are 3 screenshots of my BIOS/UEFI settings that might be relevant, I've tried changing some things but also no luck. imgur.com/a/Z3Dt0
      – verified.human
      Jun 28 '17 at 13:04










    • What are the options under "HDA audio controller" and "Depop"? Just enabled/disabled? Try disabling "Depop". If you disable "HDA audio controller", does the lspci output change?
      – dirkt
      Jun 28 '17 at 14:32










    • Tried disabling both options in the Bios, but no changes. Still no soundscards detected :-(
      – verified.human
      Jun 29 '17 at 17:42










    • I'm out of ideas. Try filing a bug with the ALSA developers. If they find a solution, don't forget to update this question with your answer.
      – dirkt
      Jun 29 '17 at 17:53
















    Thanks again for your very helpful comment. I've tried the things you suggest (see second update in first post), but unfortunately no luck. Here are 3 screenshots of my BIOS/UEFI settings that might be relevant, I've tried changing some things but also no luck. imgur.com/a/Z3Dt0
    – verified.human
    Jun 28 '17 at 13:04




    Thanks again for your very helpful comment. I've tried the things you suggest (see second update in first post), but unfortunately no luck. Here are 3 screenshots of my BIOS/UEFI settings that might be relevant, I've tried changing some things but also no luck. imgur.com/a/Z3Dt0
    – verified.human
    Jun 28 '17 at 13:04












    What are the options under "HDA audio controller" and "Depop"? Just enabled/disabled? Try disabling "Depop". If you disable "HDA audio controller", does the lspci output change?
    – dirkt
    Jun 28 '17 at 14:32




    What are the options under "HDA audio controller" and "Depop"? Just enabled/disabled? Try disabling "Depop". If you disable "HDA audio controller", does the lspci output change?
    – dirkt
    Jun 28 '17 at 14:32












    Tried disabling both options in the Bios, but no changes. Still no soundscards detected :-(
    – verified.human
    Jun 29 '17 at 17:42




    Tried disabling both options in the Bios, but no changes. Still no soundscards detected :-(
    – verified.human
    Jun 29 '17 at 17:42












    I'm out of ideas. Try filing a bug with the ALSA developers. If they find a solution, don't forget to update this question with your answer.
    – dirkt
    Jun 29 '17 at 17:53




    I'm out of ideas. Try filing a bug with the ALSA developers. If they find a solution, don't forget to update this question with your answer.
    – dirkt
    Jun 29 '17 at 17:53













    0














    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.



    Hope this helps someone.






    share|improve this answer




























      0














      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.



      Hope this helps someone.






      share|improve this answer


























        0












        0








        0






        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.



        Hope this helps someone.






        share|improve this answer














        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.



        Hope this helps someone.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Oct 25 '18 at 11:50

























        answered Oct 10 '18 at 10:34









        gamr1ukgamr1uk

        12




        12






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f373777%2frealtek-alc1220-audio-chipset-on-linux-mint-18-1%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

            is 'sed' thread safe

            How to make a Squid Proxy server?