[Bug 1193063] After configuration of audio and correct sound, the sound is noisy after next reboot till reconfiguration with yast2 again
https://bugzilla.suse.com/show_bug.cgi?id=1193063
https://bugzilla.suse.com/show_bug.cgi?id=1193063#c56
--- Comment #56 from Takashi Iwai
Answer to comment 51: I am not sure what you want? I did following:
eduard@linux-m4mf:~> more /sys/module/snd_hda_intel/parameters/power_save_controller N eduard@linux-m4mf:~> more /sys/module/snd_hda_intel/parameters
*** /sys/module/snd_hda_intel/parameters: Verzeichnis ***
What should I get here? There is not other output.
I meant to check /sys/module/snd_hda_intel/parameters/power_save file after replacing the option from power_save_controller=0 with power_save=0. The files /sys/module/*/parameters/* contain the current module parameter values. And, you can forget about YaST errors. Basically it has nothing to do with the problem itself. It seems that some wrong configuration is present, but it's harmless. There are two major problems with your device: 1. The wrong mapping of the volume control in ALC1220 codec for the line-out pin 2. The noisy output (1) is basically a hardware failure of ALC1220 chip. And that's the reason why you had to choose "headphone (unplugged)" even for the line-out. This bug should be fixable by a similar way as clevo-p95- quirk. I'm not quite sure why the existing clevo-p950 quirk caused the silent output, though. It might be due to the additional COEF setup there, or still some missing mixer configuration. (Note that, when this workaround is applied, you'll have to choose "line-out" for the line-out and "headphone" for the headphone out.) However, (2) turned out to be a totally different problem, and currently I have no concrete idea what's wrong. As already mentioned, both good-working and bad-working cases show the very same codec register dumps. So the state is identical in both. A possible reason why it worked in the past is the the runtime PM hasn't been enabled in the past by some reason (although it should have been enabled). This might the codec chip to some unstable state and the re-initialization via runtime resume doesn't work. It works after a full reset, as it seems, though. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com