Now, since #112731 was fixed, I'm getting sound just fine. However, there's one more issue probably specific to this model. When I load the kernel from a cold boot or reboot from Windows, play some sound (music, whatever), and then either shut down or reboot, I hear a loud "bang" static noise from the speakers when driver is unloading (at shutdown, but I assume that's when the driver is unloaded). This doesn't happen if I don't play any sound during the system uptime. When I boot it up next time (after when I hear the "bang" sound at shutdown and after I reboot to either Windows or Linux), I hear the same sound twice when booting either Windows or Linux (when the driver is modprobed again). One could think the Linux driver leaves the hardware in an invalid state at unload. This doesn't happen on Windows.
Created attachment 206561 [details] Recorded noise I've managed to record what I'm hearing. At 7s you can hear the sound it makes at shutdown (driver unload). At 27s you can hear what happens at boot (driver load).
The driver isn't unloaded usually at shutdown. Does the noise happen even if you mute the output before shutdown?
I'll correct myself first. It's not on the driver unload, but in between the "reboot" and "post screen" (when the hardware resets). And no, no change when I mute before I reboot.
OK, then could you try the patch below?
Created attachment 207921 [details] Test patch
Yes, that gets rid of the noise at shutdown/boot up. However, when codec is first initialized, and I run speaker-test as root (to bypass pulseaudio which would run as normal user), I still hear the similar noise before speaker-test begins outputting the sound. Similar thing happens when I switch from root to normal user (which uses pulse) after I run speaker-test as root and play any sound (the noise before it begins, later on all normal).
The rest issues are likely about the runtime PM. Does the additional patch below improve the situation?
Created attachment 208391 [details] Another patch to disable power_save_node
The latest patch doesn't fix the second issue mentioned in comment 6. However, I've noticed it's against patch_cirrus.c, while the first patch is against patch_conexant.c (conexant is the codec my system uses).
Gah, of course, it's a wrong place. Which kernel are you testing? Is it the latest 4.5-rc? If yes, try to *enable* power_save_node option, e.g. diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 6122b8ca872f..6e0030a982b4 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -901,7 +906,8 @@ static int patch_conexant_auto(struct hda_codec *codec) snd_hda_pick_fixup(codec, cxt5051_fixup_models, cxt5051_fixups, cxt_fixups); break; - case 0x14f150f2: + case 0x14f150f2: /* CX20722 */ + case 0x14f150f4: /* CX20724 */ codec->power_save_node = 1; /* Fall through */ default:
(In reply to Takashi Iwai from comment #10) > Gah, of course, it's a wrong place. > > Which kernel are you testing? Is it the latest 4.5-rc? > If yes, try to *enable* power_save_node option, e.g. > I'm now at 4.5-rc7. I'll try the following patch and report back.
The patch from Comment 10 doesn't solve my other issue.
OK, so at least it's not about the recent power-saving stuff. Then there is no much known workaround for the issue, and there is no general hint, unfortunately. It's specific to each machine, so you have to try different methods one by one, e.g. putting a delay after the codec resume, or prevent some power down, etc.
O well, I suppose it's nothing really important. The original issue has been fixed. Feel free to close the bug when the patch has landed upstream.