Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

At Fri, 22 Oct 2010 09:46:06 +0100,
Colin Guthrie wrote:
> 
> 'Twas brillig, and Jiri Slaby at 21/10/10 22:42 did gyre and gimble:
> > On 10/21/2010 11:31 PM, Takashi Iwai wrote:
> >> OK.  Maybe someone else can check it meanwhile.
> > 
> > Someone else rebooted the 13th time today and checked :):
> > $ rpm -q `rpmqpack |egrep 'alsa|asound'|sort`
> > alsa-1.0.22.git20101018-1.1.x86_64
> > alsa-firmware-1.0.23-3.7.noarch
> > alsa-oss-1.0.17-31.4.x86_64
> > alsa-plugins-1.0.23-4.5.x86_64
> > alsa-plugins-pulse-1.0.23-4.5.x86_64
> > alsa-plugins-pulse-32bit-1.0.23-4.5.x86_64
> > alsa-plugins-32bit-1.0.23-4.5.x86_64
> > alsa-utils-1.0.23-4.5.x86_64
> > libasound2-1.0.22.git20101018-1.1.x86_64
> > libasound2-32bit-1.0.23-6.5.x86_64
> > 
> > No success. I still need the revert.
> > 
> > regards,
> 
> Just tested the latest kernel patch in a "proper" (i.e. patched in
> kernel) build (as opposed to my previous out-of-tree builds).
> 
> It's working great for me (stac9200)
> 
> I tried without the userspace patch and things still work fine for me
> under this setup - it's just that PAs flat volumes do not properly
> control the Master+PCM pipeline (they both go to mute when master hits 0).

So, you mean it works without alsa-lib patch on your system?

The symptom was somehow related with the suspend or initialization.
In the early post (sorry, this wasn't cited in the mail you added to
Cc), Jiri mentioned:

  BUT, when I run pulse and it suspends the device (or whatever), all
  the levels get down to 0 back again. When I raise it and run
  mplayer, it gets to 0 immediately. If I raise it gets to 0 when
  mplayer finishes and pulse writes 'protocol-native.c: Connection
  died.'. It never raises automatically. And if I raise it during
  playback, nothing plays at all.


> But it doesn't seem to cause any other problems for me.
> 
> I'm no expert at the kernel side, but can't see much in the code that
> would cause this.
> 
> However, from Jiri's alsa-info, this looks a bit suspicious:
> 
> Simple mixer control 'Master',0
>   Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
>   Playback channels: Mono
>   Limits: Playback 0 - 64
>   Mono: Playback 40 [62%] [1620.40dB] [on]
> 
> 1620.40dB?? Really?
> 
> Is perhaps the TLV fix for min-is-mute conflicting with a db range fix?

Well, it doesn't conflict but the old alsa-lib just takes the value
as is -- i.e. the mute high bit is evaluated as a normal value.  So,
obviously it passes a wrong value for the old alsa-lib.

The above result is likely because alsa-info was generated with the
unpatched alsa-lib.  Jiri, could you regenerate alsa-info output with
the fixed alsa-lib packages?  With the fixed alsa-lib, the dB value
should be given correctly.

Anyway, judging from the fact above (giving a really wrong value), we
will have to revert the commit...


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/