On Thu, 30 Jan 2020 14:17:16 +0100, Roman Šmakal wrote: > > Dne čtvrtek 30. ledna 2020 14:07:53 CET, Takashi Iwai napsal(a): > > On Thu, 30 Jan 2020 13:07:46 +0100, > > > > Roman Šmakal wrote: > > > Dne čtvrtek 30. ledna 2020 12:57:32 CET, Takashi Iwai napsal(a): > > > > On Thu, 30 Jan 2020 12:42:01 +0100, > > > > > > > > Roman Šmakal wrote: > > > > > Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a): > > > > > > On Sat, 25 Jan 2020 23:30:32 +0100, > > > > > > > > > > > > Roman Šmakal wrote: > > > > > > > Hi, > > > > > > > > > > > > > > this still seem to be an issue. After startup everything works > > > > > > > well > > > > > > > until > > > > > > > the laptop goes to suspend. > > > > > > > > > > > > > > Tried pretty much everything basic user can do (unmutes, rmmods > > > > > > > and so > > > > > > > on), > > > > > > > still no way to wake the output. ALSA seems to be thinking, that > > > > > > > output is > > > > > > > active, you can set volume and stuff, but nothing happens. > > > > > > > > > > > > > > ALSA info: > > > > > > > http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be420f83 > > > > > > > a373 > > > > > > > > > > > > > > Related links: > > > > > > > https://www.reddit.com/r/archlinux/comments/4nwzua/ > > > > > > > no_sound_after_suspend_killing_or_restarting/ > > > > > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404 > > > > > > > > > > > > The first thing to check is to compare alsa-info.sh outputs before > > > > > > and > > > > > > after the suspend. > > > > > > > > > > > > Also pass snd_hda_codec.dump_coef=1 module option to enable the COEF > > > > > > dump. This will give more information in alsa-info.sh outputs. > > > > > > > > > > > > > > > > > > Takashi > > > > > > > > > > Okay, i did some comparing with module option enabled. > > > > > > > > > > > > > > > Sound working > > > > > http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb7588 > > > > > > > > > > Sound not working: > > > > > http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff8d4d > > > > > > > > > > What's wierd to me is, that on the row 521 there is change in aplay > > > > > Subdevices from 1/1 to 0/1. > > > > > > > > > > Also, state.PCH control 18 shows change in playback channel map. > > > > > > > > > > Any other thing i can check or try to dofor debuging? > > > > > > > > You passed a wrong option. The option is for snd_hda_codec module. > > > > > > > > So either create a modprobe.d/*.conf file containing: > > > > options snd_hda_codec dump_coef=1 > > > > > > > > or pass snd_hda_codec.dump_coef=1 at boot cmdline option. > > > > > > > > BTW, it'd be better to get the outputs with --no-upload option of > > > > alsa-info.sh, and attach them. > > > > > > > > Last but not least, please don't drop Cc to ML unless you need to do > > > > so. > > > > > > > > > > > > thanks, > > > > > > > > Takashi > > > > > > Alright, my bad, i'm new to this. > > > > > > Attaching alsainfos with proper module options, no big difference though. > > > > OK, so it has the codec has COEF things and there is no significant > > difference between those two outputs. It implies that something > > outside HD-audio bus is needed and it's probably done by BIOS. > > > > > > Takashi > > OK, so this means that this report is invalid and kernel developers should > check this out? > > How should i proceed now? It's all about vendor-specific implementation, so the only h/w vendor knows... Unfortunately (or fortunately) Conexant codecs are well-mannered and there are few quirks. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
