'Twas brillig, and Takashi Iwai at 22/10/10 10:02 did gyre and gimble:
At Fri, 22 Oct 2010 09:46:06 +0100, Colin Guthrie wrote:
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?
Yeah everything still works OK, but the infamous "mute at 16%" issue is obviously unresolved.
The difference with the kernel patch applied vs. not applied is that alsamixer reports the device volume as "mute" when Master is at 0 with the patch and it reports it as -46.5dB without the patch.
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.
Yeah, I did read that via the lklm archive. It's very odd that the volumes change when pulse suspends the device... I could understand if it changed when it opens them again (it will look at the product of the mixers in the pipeline - e.g. Master+PCM - then work out the over all dB then rearrange the sliders so that the same dB is ultimately obtained, but perhaps via a different combination of mixer positions (e.g. it will use all of Master first and only then adjust PCM). Overall the volume itself should remain at the same dB tho'.
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.
Right. This actually probably explains things thinking about it...
Because the range is incorrectly reflected without the alsa-lib patch. PA tries to set the volume to a "sensible" dB value.
This value would likely cause Master to be set to 0 (seeing as 1620.40dB is 40, $sensible_dB is likely mapped to 0). When the device hits 0, the kernel patch causes this to be properly reflected as "mute" (or -infdB?) and thus PA notices this and sets both Master and PCM to 0 for that reason.
That might not be exactly what's going on, but it's probably some similar variant thereof.
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.
I'm surprised that the updated alsa-lib did not fix this problem. We're now pushing out both the kernel and userspace fix, so I'll see if anyone is affected by this in the same way as Jiri.
Jiri, when you tested the userspace updated package did you remember to restart PA? If not then the test will not have worked as expected (the fact that both your subsequent alsa-info's have sensible dB values for Master suggests that the userspace fix is installed). Also when Takashi asked for updated alsa-info script above, he meant to do it with both the kernel and userspace patches applied.
Anyway, judging from the fact above (giving a really wrong value), we will have to revert the commit...
Yes, sadly that seems so. Any bright idea on how to fix this in a less invasive (i.e. backwards compatible) way?
Cheers
Col