With the audio codec autosuspend being enabled on Fedora rawhide, we now get frequent glitches on the X1 Carbon 3rd generation (only on the headphone jack). These glitches happen both when the codec is suspended/resumed and when plugging in/out headphones. It may be appropriate to disable autosuspend on this particular codec revision or machine.
Hi All, The plan to fix this is to use a blacklist for devices on which the power_save option causes issues and I need your help to populate this blacklist, getting your device on this list now means that things will just work when you upgrade to F28 later. First of all to test this I need you to (temporarily) switch to running a Fedora 28 kernel, download these 2 files: https://kojipkgs.fedoraproject.org//packages/kernel/4.15.0/1.fc28/x86_64/kernel-core-4.15.0-1.fc28.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/kernel/4.15.0/1.fc28/x86_64/kernel-modules-4.15.0-1.fc28.x86_64.rpm (from: https://koji.fedoraproject.org/koji/buildinfo?buildID=1021748) And then run: sudo rpm -ivh kernel-core-4.15.0-1.fc28.x86_64.rpm kernel-modules-4.15.0-1.fc28.x86_64.rpm And reboot into the new kernel. cat /sys/module/snd_hda_intel/parameters/power_save Should now output 1 and this should give you the sound problems this bug was originally about again. If not do "uname -r" to make sure you are running the 4.15.0-1.fc28.x86_64 kernel and if you are, you got lucky and the bug got fixed in the latest kernel :) So assuming you can now reproduce the problem, it is time to create a blacklist entry: 1) Download: https://fedorapeople.org/~jwrdegoede/90-hda-powersave.rules and copy it to /etc/udev/rules.d 2) Download: https://fedorapeople.org/~jwrdegoede/90-snd_hda_intel.hwdb and copy it to /etc/udev/hwdb.d 3) Edit /etc/udev/hwdb.d/90-snd_hda_intel.hwdb and add an entry for your device there, lets take a look at the example entry: # Match string formats: # snd_hda_intel:<pci-subsys-vendor-id>:<pci-subsys-device-id>:dmi:<dmi string> snd_hda_intel:0x1849:0x5892:dmi:*rvnASRock:rnB150MPro4S/D3:* SND_HDA_INTEL_POWERSAVE=0 There are 3 device specific parts you need to fill in, lets star with the pci-subsys-vendor-id and pci-subsys-device-id. Run: lspci | grep "HD Audio" This outputs e.g.: 00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31) Now get detailed info on that device: [hans@shalem ~]$ lspci -v -n -s 00:1f.3 00:1f.3 0403: 8086:a170 (rev 31) Subsystem: 1849:5892 ... And after the Subsystem: are the values you are looking for. The last device specific bit you need is the dmi modalias for your system: cat /sys/class/dmi/id/modalias On my example system this gives: dmi:bvnAmericanMegatrendsInc.:bvrP7.00:bd12/06/2016:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnB150MPro4S/D3:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: Notice that I've shortened this to: dmi:*rvnASRock:rnB150MPro4S/D3:* Replacing uninteresting bits with a simple "*" as well as replacing the bios-data (bd) and bios-version (bvr) fields as those may vary depending on the installed BIOS version and we want to match all versions. Add a new entry for your device using the info from above. 4) To use this new info run: sudo systemd-hwdb update sudo udevadm trigger 5) Verify that power_save now is 0: cat /sys/module/snd_hda_intel/parameters/power_save 6) Reboot, check that power_save is set to 0 again and that the sound problems are gone. As mentioned in the 90-snd_hda_intel.hwdb file I've to insist on people filing a bug for this at https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers using component "Sound(ALSA)" and then add a link to the filed bug report as a comment to the hwdb entry you've added for this. Once you've a working hwdb entry with a comment to a bugzilla.kernel.org bug for this, please attach your modified 90-snd_hda_intel.hwdb here. Once I've gathered a few entries I will submit these files for upstream systemd inclusion. Thanks & Regards, Hans
Thanks Hans! One quick note. On this machine one needs to grep for "High Definition Audio" in the lspci output. Anyway, the following works fine here. Full DMI modalias was dmi:bvnLENOVO:bvrN14ET34W(1.12):bd02/04/2016:svnLENOVO:pn20BTS1N706:pvrThinkPadX1Carbon3rd:rvnLENOVO:rn20BTS1N706:rvrNODPK:cvnLENOVO:ct10:cvrNone: ---- # X1 Carbon 3rd Generation with ALC3232 codec # https://bugzilla.kernel.org/show_bug.cgi?id=198611 snd_hda_intel:0x17aa:0x2227:dmi:*:svnLENOVO:*:pvrThinkPadX1Carbon3rd:rvnLENOVO:* SND_HDA_INTEL_POWERSAVE=0
FYI: I've submitted a pull-req to systemd implementing a hwdb based blacklist for models like the X1 3d gen where CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1 is causing issues. The initial hwdb-file for this contains an entry for the X1 3d gen: https://github.com/systemd/systemd/pull/8128 Note this is meant as a temporary workaround, hopefully we can figure out a proper fix for this.
So the pull-req did not last long, upstream systemd/udev had some rightful worries about this approach, see: https://github.com/systemd/systemd/pull/8128 So now the plan is changed to deal with this inside the kernel instead, using pci subsys vendor- and device-id matching. This will also allow the quirk to disable-power-saving to be removed in sync with any kernel fixes which make it no longer necessary. Specifically for the X1 carbon 3th gen I think I may have found a better fix, quoting my comment from https://bugzilla.kernel.org/show_bug.cgi?id=198611 : Can you try building a kernel with: sound/pci/hda/patch_realtek.c modified to contain an entry for the "Thinkpad X1 Carbon 3th" pointing to the ALC292_FIXUP_TPT440_DOCK quirk, perhaps that will help? As you know the subsys pci-ids are: 0x17aa, 0x2227.
I've prepared a scratch kernel-build (note still building atm) with the discussed power-saving blacklist here: https://koji.fedoraproject.org/koji/taskinfo?taskID=25234129 Here are instructions for how to download and test a kernel from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt After booting into the new kernel, do: dmesg | grep "is on the power_save blacklist" This should return a line with the PCI subsys ids of your HDA card, also: "cat /sys/module/snd_hda_intel/parameters/power_save" should return "0" and last but not least, your sound should work without any issues of course.
Forget about that test-kernel please, it is no good. I will prepare a new one.
A fixed test-build is now building here, please test once it is done: https://koji.fedoraproject.org/koji/taskinfo?taskID=25235331
Correction, forget about the "cat /sys/module/snd_hda_intel/parameters/power_save" output, that will return -1 in the new version and not be useful for seeing if the quirk gets applied.
The quirk is getting applied on the machine in question and autosuspend is turned off. And now I notice that the detection doesn't work properly, detecting a headphone as headset. Somewhat separate issue though. :-/
Created attachment 1421139 [details] alsa-info.sh output Same problem (using headphones) on my Dell machine (using ALC3234). I attached the output of alsa-info.sh .
Hi, (In reply to Dmytro Taranovsky from comment #10) > Created attachment 1421139 [details] > alsa-info.sh output > > Same problem (using headphones) on my Dell machine (using ALC3234). I > attached the output of alsa-info.sh . Headset vs headphones detection is a different issue and a long standing issue with Dell laptops which I'm not sure we can easily fix. It is best to file a bug for this upstream: https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers And then as component pick Sound(ALSA) also please attach your alsa-info.sh output there. Regards, Hans
(In reply to Hans de Goede from comment #11) Sorry, by the same problem, I meant audible glitch when audio starts and when it suspends (i.e. a few seconds after audio stops playing).
(In reply to Dmytro Taranovsky from comment #12) > (In reply to Hans de Goede from comment #11) > Sorry, by the same problem, I meant audible glitch when audio starts and > when it suspends (i.e. a few seconds after audio stops playing). Ok, in that case please file a new Fedora bug against component kernel and attach the file generated by the "alsa-info.sh" command there.
(In reply to comment #12 and comment #13) After an update to kernel 4.16.11 (along with other updates), the problem was apparently fixed on my machine.
(In reply to Dmytro Taranovsky from comment #14) > (In reply to comment #12 and comment #13) > After an update to kernel 4.16.11 (along with other updates), the problem > was apparently fixed on my machine. That is good to hear, thank you for the update.