Bug 42825 - [3.1.8 -> 3.2.4 regression] Mute on master channel disappeared on a Thinkpad T500
[3.1.8 -> 3.2.4 regression] Mute on master channel disappeared on a Thinkpad...
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA)
All Linux
: P1 normal
Assigned To: Jonathan Nieder
:
Depends on:
Blocks: 42566
  Show dependency treegraph
 
Reported: 2012-02-26 15:20 UTC by S. G.
Modified: 2012-03-28 18:17 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.2.0-1-amd64
Tree: Mainline
Regression: Yes


Attachments
alsainfo output running kernel 3.1.8 (21.10 KB, text/plain)
2012-02-26 15:20 UTC, S. G.
Details
alsainfo output running kernel 3.2.6 (20.27 KB, text/plain)
2012-02-26 15:23 UTC, S. G.
Details
Fix patch (3.92 KB, patch)
2012-02-27 19:08 UTC, Takashi Iwai
Details | Diff
alsainfo output running patched kernel 3.2.6 (20.35 KB, text/plain)
2012-02-29 15:32 UTC, S. G.
Details
alsainfo output Thinkpad SL500 (24.07 KB, text/plain)
2012-03-12 17:25 UTC, Jakob Matthes
Details

Description S. G. 2012-02-26 15:20:09 UTC
Created attachment 72482 [details]
alsainfo output running kernel 3.1.8

The mute function disappeared after upgrading from kernel version 3.1.8 to version 3.2.4.
Comment 1 S. G. 2012-02-26 15:23:17 UTC
Created attachment 72483 [details]
alsainfo output running kernel 3.2.6

This feature was initially detect with kernel 3.2.4. But further testing took place with kernel 3.2.6.

See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660994
Comment 2 Takashi Iwai 2012-02-26 15:42:54 UTC
This codec chip has really no mute control, thus it's actually a fix that removes the invalid control.
Comment 3 Jonathan Nieder 2012-02-26 15:50:49 UTC
Thanks, that makes sense.

The original symptom S.G. experienced was pulseaudio's mute control no longer working.  Sounds like a pulseaudio bug, then.  Unfortunately not listed at [1].  Known?  Am I correct in assuming this would have been a problem with other cards already?

[1] https://bugs.freedesktop.org/buglist.cgi?list_id=1329&product=PulseAudio
Comment 4 S. G. 2012-02-26 16:25:03 UTC
(In reply to comment #2)
> This codec chip has really no mute control, thus it's actually a fix that
> removes the invalid control.

How comes that mute control even worked with kernel 3.1.8?
Comment 5 S. G. 2012-02-26 16:40:40 UTC
(In reply to comment #3)
> Thanks, that makes sense.
> 
> The original symptom S.G. experienced was pulseaudio's mute control no longer
> working.  Sounds like a pulseaudio bug, then.  Unfortunately not listed at [1].
>  Known?  Am I correct in assuming this would have been a problem with other
> cards already?
> 
> [1] https://bugs.freedesktop.org/buglist.cgi?list_id=1329&product=PulseAudio

To make it clear: Mute always worked on my Thinkpad T500,
- with ALSA only up to the day Gnome 3 was introduced to debian-testing
- with pulseaudio (utilizing ALSA?) which came in with Gnome 3 up to the day kernel version 3.2.x showed up on debian-testing.

So I am in doubt whether this should be a pulseaudio issue.
Comment 6 Takashi Iwai 2012-02-26 20:22:44 UTC
The lowest volume would be likely working as mute although the hardware doesn't expose any mute capability.  So, it's just a coincidence in the older version as if the mute looked working.

It'd be possible to implement a "fake" mute control to set the lowest volume, if the hardware really behaves so.  Or, maybe forcibly setting the mute flag in TLV_DB_SCALE setup would suffice for PA.  It'd be a minimal change that is even mergeable for 3.3.
Comment 7 S. G. 2012-02-26 22:43:19 UTC
Takashi

I am afraid we are looking at this issue from different perspectives:

From your comments I understand you are looking at what the hardware offers, and there's no mute control, it never was.

I am looking at the users interface as presented by alsamixer, it offered a mute control at least up to kernel 3.1.8 which _did_ work by what means soever. With kernel 3.2.x and exactly the same version of alsamixer this mute control vanished.

I would expect that ALSA (and alsamixer?) covers deficiencies of the hardware where possible, but may be I am wrong and this up to someone higher in the software stack.

My suggestion is to re-implement things how they were with kernel 3.1.8 but from my observations a 'fake' mute control setting the lowest volume would result in the same user experience, i.e., sound on/off. - you decide.
Comment 8 Takashi Iwai 2012-02-27 10:01:14 UTC
It doesn't matter to look from which perspective :)  It's a driver issue, after all.  I know well what the original bug report means.  The fix was planned but not done yet just because it was Sunday.
(And once when the driver provides the mute control, from the user-space POV, there is no difference how it's implemented.)

Back to some facts: as mentioned, the hardware doesn't expose the mute control at all, but the old kernel did abuse some stuff (e.g. EAPD) to provide a master mute.  In the recent code, the driver was rewritten to be more generic, but relying mostly on the codec information the chip exposes and on the BIOS information.  Both don't show any sign of mute things, thus the recent driver didn't give the mute control.

Since the code-base is fairly different between the old and the new codes, you can't forward-port the old stuff.  Instead, it's better to fix it right by overriding the hardware limitation forcibly; it's what I called as a "fake" control.

Now, the question to you is to check whether the hardware really mutes when you set the volume to the lowest.  Once when it's confirmed, I'll provide some test patches.
Comment 9 S. G. 2012-02-27 17:49:19 UTC
Thank you for your explanations.

To my ears setting the volume to the lowest is identical to muting. Nothing's to be heard.

I am looking forward to your fix.
Comment 10 Takashi Iwai 2012-02-27 19:07:51 UTC
OK, then could you try the patch below?
This should implement a fake mute control.
Comment 11 Takashi Iwai 2012-02-27 19:08:25 UTC
Created attachment 72486 [details]
Fix patch
Comment 12 S. G. 2012-02-29 15:30:10 UTC
Status with a patched kernel 3.2.6:

With alsamixer there are three new mute controls, with master, headphone and speaker. Master mute works as expected. These extra mutes (headphone, speaker) are functional as well but seem redundant to me.

When utilizing mute controls of Cairo-Dock sometimes master, headphone and speaker are muted simultaneously but on unmute only the master control is affected which results in no sound due to the still muted speaker and handphone control. I assume this is not a kernel driver issue.

So the only open question is whether those speaker and headphone mute controls exist intentionally or by accident.
Comment 13 S. G. 2012-02-29 15:32:21 UTC
Created attachment 72499 [details]
alsainfo output running patched kernel 3.2.6

For additional information see this alsainfo.
Comment 14 Takashi Iwai 2012-02-29 15:33:40 UTC
The speaker and headphone mute controls are present intentionally.  The all-mute things are because of PulseAudio, usually.  And there is a known bug of PA which leaves some child elements as muted at unmting sometimes.
Comment 15 S. G. 2012-02-29 15:50:37 UTC
Good to know :-)

From my point of view this bug can be set to resolved now.
Comment 16 Takashi Iwai 2012-02-29 16:42:56 UTC
OK, I merged the patch now to the upstream tree.
Comment 17 Jonathan Nieder 2012-02-29 17:08:24 UTC
(In reply to comment #16)
> OK, I merged the patch now to the upstream tree.

Thanks! \o/

Are other cards likely to need this kind of fix, too?  Do you think pulseaudio should be changed somehow to cope better with missing mute controls?  What should happen when there really is no way to mute in hardware?
Comment 18 Jakob Matthes 2012-03-09 17:18:37 UTC
(In reply to comment #8)
> Now, the question to you is to check whether the hardware really mutes when you
> set the volume to the lowest.  Once when it's confirmed, I'll provide some test
> patches.

The fake mute option is not satisfactory on a Thinkpad SL500: the sound is very quiet but still audible.

00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
Card: HDA Intel
Chip: Intel Cantiga HDMI

If it is helpful I can provide you with a full alsainfo output in a few days.
Comment 19 Florian Mickler 2012-03-09 20:45:43 UTC
A patch referencing this bug report has been merged in Linux v3.3-rc6:

commit 3868137ea41866773e75d9ac4b9988dcc361ff1d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Feb 27 15:00:58 2012 +0100

    ALSA: hda - Add a fake mute feature
Comment 20 Jonathan Nieder 2012-03-09 20:54:33 UTC
(In reply to comment #18)

> The fake mute option is not satisfactory on a Thinkpad SL500: the sound is very
> quiet but still audible.

Thanks.  Alas.

> If it is helpful I can provide you with a full alsainfo output in a few days.

Yes, that would be helpful.
Comment 21 Jakob Matthes 2012-03-12 17:25:29 UTC
Created attachment 72569 [details]
alsainfo output Thinkpad SL500
Comment 22 Takashi Iwai 2012-03-12 17:28:25 UTC
Can anyone check whether the mute switch (and possible the LED) works with sound-unstable tree below?  The necessary fixes are found in topic/cxt-fix branch, but it's also merged back to master branch, too.
    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
Comment 23 Jakob Matthes 2012-03-15 20:24:19 UTC
Takashi: I have built today from your master branch, the mute switch is there and works as advertised above (fake mute). I do not know which LED is meant in this context.

Regarding the fake mute I have two observations:
1) If I set the PCM mixer to 0 I cannot hear anything (the PCM mixer has no mute toggle) unlike the fake mute option / volume 0 for Master mixer.
2) I have set the powersave option of snd_hda_intel to 1s. Powersave mode is only activated if no application plays sound -- regardless of the mute status of the Master mixer.
Comment 24 Jonathan Nieder 2012-03-28 18:16:22 UTC
The missing mute control on T500 reported by S.G. was fixed by 3868137ea418. Closing.

If the incomplete mute on the Thinkpad SL500 reported by Jakob Matthes is still present, it's probably worth opening a new bug to track it.

Note You need to log in before you can comment on or make changes to this bug.