[alsa-devel] No sound and systemd journal filling when inserting headphones when power-saving is enabled

Takashi Iwai tiwai at suse.de
Thu Feb 26 09:12:18 CET 2015


At Wed, 25 Feb 2015 22:15:32 +0000,
Dang Sananikone wrote:
> 
> On 25 February 2015 at 06:59, Takashi Iwai <tiwai at suse.de> wrote:
> 
> > At Tue, 24 Feb 2015 22:26:32 +0000,
> > Dang Sananikone wrote:
> > >
> > > On 24 February 2015 at 20:57, Takashi Iwai <tiwai at suse.de> wrote:
> > >
> > > > At Tue, 24 Feb 2015 20:11:58 +0000,
> > > > Dang Sananikone wrote:
> > > > >
> > > > > Thanks, in that case I'll simply attach the files to this post.
> > There are
> > > > > two files:
> > > > >
> > > > >  * alsa-info-notworking.txt: This is the alsa info generated when
> > > > > power-saving is enabled and after "speaker-test" has been invoked.
> > > > >  * alsa-info-working.txt: This is the alsa info generated when
> > > > power-saving
> > > > > is disabled and after "speaker-test" has been invoked.
> > > > >
> > > > >
> > > > > To reproduce the problem:
> > > > >
> > > > > Prerequisite:
> > > > > Set "options snd_hda_intel power_save=1"
> > > > >
> > > > > Instructions:
> > > > > 1. Boot up laptop.
> > > > > 2. Insert headphone socket into jack.
> > > > > 3. In terminal, type "speaker-test -c 2".
> > > > >
> > > > > Expected Result:
> > > > > The speaker-test program hangs, and the systemd journal starts
> > filling up
> > > > > with "sound hdaudioC0D0: hda-codec: out of range cmd
> > 0:1:716:ffffffff"
> > > > > messages.
> > > >
> > > > OK, then try to pass power_save_controller=0 option to snd-hda-intel
> > > > module.  It might be that the controller gets screwed up by some
> > > > reason by power-saving.
> > > >
> > >
> > > If I've understood you correctly I've set the following options: "options
> > > snd_hda_intel power_save=1 power_save_controller=0".
> > >
> > > Then I've plugged in my headphones before invoking speaker-test. With no
> > > audio playing I hear a blip sound every second.
> >
> > Every second?  Is this equal with the length you specified to
> > power_save option?  i.e. if you pass power_save=10, the frequency of
> > blip noise changes, too?
> >
> 
> Yes, it is equal to the value specified in the power_save option. I changed
> power_save to 10 and the frequency changed to 10 seconds.

OK, then this is some artifact by the codec power down.
Maybe we can reduce it by tweaking something, e.g. skipping the pin
shutdown or putting some longer delay at EAPD flip.  But it's
basically a different issue from the hang you reported.


> > > Then I invoke "speaker-test -c 2" and I hear the speaker test audio I
> > > expect to hear. The program does not hang. After killing the program and
> > > with no audio playing I hear the blip sound every second.
> >
> > So, the problem was basically the HD-audio controller screwed up by
> > the power-saving.  BTW, didn't you see the same problem with the
> > explicit suspend/resume (S3 and S4)?  For testing it, try a bigger
> > value in power_save so that you go to S3/S4 before the power save is
> > triggered.
> >
> >
> I set "options snd_hda_intel power_save=600", then performed the following
> actions:
> 
>    * Reboot laptop.
>    * Invoke "speaker-test -c 2", and wait for audio to play.
>    * Enter suspend mode by calling "systemctl suspend" in another terminal
> ---> audio stops playing.
>    * Exit suspend mode ---> audio restarts playing.
> 
> So, the same problem does not exist when entering/exiting suspend state.
> 
> 
> > > > If this still doesn't help, we need more logs.  Build the kernel with
> > > > tracing support, and get the HD-audio verb traces as
> > > > Documentation/sound/alsa/HD-Audio.txt, section Tracepoints.
> > > >
> > > >
> > > > Takashi
> > > >
> > >
> > > Going back to this setting I set out to get the HD-audio verbs to provide
> > > more information: "options snd_hda_intel power_save=1".
> > >
> > > I've attached the trace file which was generated after following your
> > > instructions (I think the kernel already had tracing support enabled
> > > judging by the /proc/config.gz config parameters).
> >
> > The trace already shows the bad read from the controller, so it's
> > likely an issue in the HDA controller and/or communication.
> >
> > In anyway, below is a patch to disable runtime PM of the controller
> > again.  It's equivalent as passing power_save_controller=1.  Could you
> > give it a test?
> >
> >
> >
> I set "options snd_hda_intel power_save=1", then built and installed the
> kernel with the patched file. Invoking "speaker-test -c 2" caused no
> program hang and the audio was what I expected. Upon stopping the program I
> could hear the periodic blip. Upon repeated test, sometimes there was a
> periodic blip, sometimes there wasn't.

OK, I'll queue the patch.


Takashi


More information about the Alsa-devel mailing list