[alsa-devel] No speaker output with kernel 3.15 and later

Steven Newbury steve at snewbury.org.uk
Sat Jul 12 01:20:45 CEST 2014


On Tue, 2014-07-08 at 12:32 +0200, Takashi Iwai wrote:
> At Mon, 07 Jul 2014 17:05:43 +0100,
> Steven Newbury wrote:
> >  On Mon, 2014-07-07 at 17:41 +0200, Takashi Iwai wrote:
> >     > At Mon, 07 Jul 2014 16:34:10 +0100,
> >     > Steven Newbury wrote:
> >     > >  On Tue, 2014-07-01 at 13:54 +0200, Takashi Iwai wrote:
> >     > > >  At Tue, 01 Jul 2014 12:49:32 +0100,
> >     > > >  Steven Newbury wrote:
> >     > > > >   On Mon, 2014-06-30 at 11:24 +0200, Takashi Iwai 
> > wrote:
> >     > > > > >   At Sun, 29 Jun 2014 15:09:56 +0100,
> >     > > > > >   Steven Newbury wrote:
> >     > > > > > >    I sent
> >     > > > > > >   Takashi an email mentioning this regression a 
> > month ago,
> >     > > > > > > and
> >     > > > > > >    it's
> >     > > > > > >   taken me this long to send this email... :-$
> >     > > > > > >    Since updating to
> >     > > > > > >   kernel versions >=3.15 I've had no audio from my
> >     > > > > > >    laptop speakers.
> >     > > > > > >   Earlier versions worked fine.
> >     > > > > > >    It's a CLEVO W270EUQ laptop.  The
> >     > > > > > >   output mixer device is showing up,
> >     > > > > > >    but no sound comes out at any
> >     > > > > > >   volume level.
> >     > > > > > >    As requested I've attached compressed 
> > alsa-info.sh
> >     > > > > > >   output for both the
> >     > > > > > >    working and non-working cases.
> >     > > > > > >    I'm perfectly
> >     > > > > > >   willing to test patches etc.
> >     > > > > >   Hm, I see no significant difference between 3.14 
> > and 3.15
> >     > > > > >  alsa-info.sh
> >     > > > > >   outputs, and there's been very little change for 
> > VIA codecs
> >     > > > > >  between
> >     > > > > >   these versions.  So, in short, I have no idea what 
> > went
> >     > > > > > wrong.
> >     > > > > >   Could you double-check whether it's really a 
> > kernel issue?
> >     > > > > >   That is, switch between 3.14 and 3.15 and confirm 
> > the
> >     > > > > > problem
> >     > > > > >  happens
> >     > > > > >   only with 3.15.  Also, for testing the sound, try 
> > like
> >     > > > > >           % aplay -Dplughw -vv foo.wav
> >     > > > >   Checked again.
> >     > > > >   3.16-rc2: silence
> >     > > > >   3.14.3: works fine
> >     > > >  Then I'd suggest to bisect between 3.14 and 3.15.
> >     > >  Somewhat surprisingly I ended up here:
> >     > >  dcb32ecd9a533f47ab652c5c5680bc50a7a822cd is the first bad 
> > commit
> >     > >  commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd
> >     > >  Author: Anssi Hannula <anssi.hannula at iki.fi>
> >     > >  Date:   Tue Apr 8 12:36:42 2014 +0300
> >     > >      ALSA: hda - Do not assign streams in reverse order
> >     > >      Currently stream numbers are assigned in reverse 
> > order.
> >     > >      Unfortunately commit 7546abfb8e1f9933b5 ("ALSA: hda -
> >     > > Increment
> >     > >      default stream numbers for AMD HDMI controllers") 
> > assumed
> >     > > this was not
> >     > >      the case (specifically, it had the "old cards had 
> > single
> >     > > device only"
> >     > >      => "extra unused stream numbers do not matter" 
> > assumption),
> >     > > causing
> >     > >      non-working audio regressions for AMD Radeon HDMI 
> > users.
> >     > >      Change the stream numbers to be assigned in forward 
> > order.
> >     > >      The benefit is that regular audio playback will still 
> > work
> >     > > even if the
> >     > >      assumed stream count is too high, downside is that a 
> > too high
> >     > > stream
> >     > >      count may remain hidden.
> >     > >      Bugzilla: 
> > https://bugs.freedesktop.org/show_bug.cgi?id=77002
> >     > >      Reported-by: Christian Güdel <cg at dmesg.ch>
> >     > >      Signed-off-by: Anssi Hannula <anssi.hannula at iki.fi>
> >     > >      Tested-by: Christian Güdel <cg at dmesg.ch> # 3.14
> >     > >      Cc: Alex Deucher <alexander.deucher at amd.com>
> >     > >      Signed-off-by: Takashi Iwai <tiwai at suse.de>
> >     > >  :040000 040000 6ed3a982a9600333b07a42169db5173fa75b8618
> >     > > b7ff28d00007f988221ba58c9d3f501fdb3a7583 M        sound
> >     >
> >     > Interesting.  Does reverting this commit fix the issue?
> >     > Just run "git revert 
> > dcb32ecd9a533f47ab652c5c5680bc50a7a822cd", and
> >     > test it.
> >     >
> >     I just did this on top of my rebased local git tree off 
> > linus/master
> >     and indeed reverting does make the speakers work again.*
>  
> OK, thanks for confirmation.
> So, by some reason, the controller (or codec) needs to use the last
> entry (in this case it's Panther Point).  I cannot understand why 
> this
> fails, but it's so...
>  
> The patch below does revert conditionally only for Intel controller
> chips.  This should work instead of git revert.  Let me know if it
> really works for you.
>  
Indeed t works.

> But, we still want to understand why.  Maybe assigning the device
> manually to an explicit value and figuring out which dev# doesn't 
> work
> would be helpful.
How do you want me to test this?

>  
>  
> thanks,
>  
> Takashi
>  
> ---
> diff --git a/sound/pci/hda/hda_controller.c 
> b/sound/pci/hda/hda_controller.c
> index 06f39c126ba4..8337645aa7a5 100644
> --- a/sound/pci/hda/hda_controller.c
> +++ b/sound/pci/hda/hda_controller.c
> @@ -194,7 +194,8 @@ azx_assign_device(struct azx *chip, struct 
> snd_pcm_substream *substream)
>                                  dsp_unlock(azx_dev);
>                                  return azx_dev;
>                          }
> -                        if (!res)
> +                        if (!res ||
> +                            (chip->driver_caps & AZX_DCAPS_REVERSE_ASSIGN))
>                                  res = azx_dev;
>                  }
>                  dsp_unlock(azx_dev);
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 75b52c4cd70d..dfc88831f1be 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -272,7 +272,7 @@ enum {
>  /* quirks for Intel PCH */
>  #define AZX_DCAPS_INTEL_PCH_NOPM \
>          (AZX_DCAPS_SCH_SNOOP | AZX_DCAPS_BUFSIZE | \
> -         AZX_DCAPS_COUNT_LPIB_DELAY)
> +         AZX_DCAPS_COUNT_LPIB_DELAY | AZX_DCAPS_REVERSE_ASSIGN)
>  #define AZX_DCAPS_INTEL_PCH \
>          (AZX_DCAPS_INTEL_PCH_NOPM | AZX_DCAPS_PM_RUNTIME)
> diff --git a/sound/pci/hda/hda_priv.h b/sound/pci/hda/hda_priv.h
> index 33eb5d027d38..949cd437eeb2 100644
> --- a/sound/pci/hda/hda_priv.h
> +++ b/sound/pci/hda/hda_priv.h
> @@ -166,6 +166,7 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO1, SDO2, 
> SDO3 };
>  #define AZX_DCAPS_BUFSIZE        (1 << 21)        /* no buffer size alignment */
>  #define AZX_DCAPS_ALIGN_BUFSIZE        (1 << 22)        /* buffer size alignment 
> */
>  #define AZX_DCAPS_4K_BDLE_BOUNDARY (1 << 23)        /* BDLE in 4k boundary 
> */
> +#define AZX_DCAPS_REVERSE_ASSIGN (1 << 24)        /* Assign devices in 
> reverse order */
>  #define AZX_DCAPS_COUNT_LPIB_DELAY  (1 << 25)        /* Take LPIB as delay 
> */
>  #define AZX_DCAPS_PM_RUNTIME        (1 << 26)        /* runtime PM support */
>  #define AZX_DCAPS_I915_POWERWELL (1 << 27)        /* HSW i915 powerwell 
> support */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140712/d421e636/attachment.sig>


More information about the Alsa-devel mailing list