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