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.
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
This codec chip has really no mute control, thus it's actually a fix that removes the invalid control.
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
(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?
(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.
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.
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.
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.
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.
OK, then could you try the patch below? This should implement a fake mute control.
Created attachment 72486 [details] Fix patch
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.
Created attachment 72499 [details] alsainfo output running patched kernel 3.2.6 For additional information see this alsainfo.
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.
Good to know :-) From my point of view this bug can be set to resolved now.
OK, I merged the patch now to the upstream tree.
(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?
(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.
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
(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.
Created attachment 72569 [details] alsainfo output Thinkpad SL500
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
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.
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.