On Sun Oct 15 09:50:43 Tanu Kaskinen wrote: > On Sat, 2017-10-14 at 18:12 +0200, Guenter Milde wrote: I reported the problem to the alsa devs: https://bugzilla.kernel.org/show_bug.cgi?id=197309 The following discussion is about a workaround in pulseaudio in case this cannot be solved upstream. > > > analog-output-speaker used to have "switch = mute" for Headphone, but > > > that was changed in this commit: > > > https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=22aac4e9fdb3786178f7815a0cb2150f588b1582 > > I agree that generally, it is preferable to switch off the headphone > > control if headphones are not plugged in. However, if the alternative > > is not any sound from the speakers, muting the headphones (instead of > > switching off) is still an acceptable workaround. > I don't know what you mean by "muting the headphones (instead of > switching off)". The alsa mixer switch only has two states. "Muted" and > "switched off" mean the same thing. I mean the following change in the path configuration: --- /usr/share/pulseaudio/alsa-mixer/paths/analog-output-speaker.conf 2017-06-18 18:03:31.000000000 +0200 +++ /analog-output-speaker-only-mute.conf 2017-10-18 10:12:48.000000000 +0200 @@ -1,4 +1,4 @@ -# This file is part of PulseAudio. +# This file is based on PulseAudio's analog-output-speaker.conf. # # PulseAudio is free software; you can redistribute it and/or modify # it under the terms of the GNU Lesser General Public License as @@ -13,7 +13,9 @@ # You should have received a copy of the GNU Lesser General Public License # along with PulseAudio; if not, see <http://www.gnu.org/licenses/>. -; Path for mixers that have a 'Speaker' control +; Path for devices where the speaker does not work if the 'Headphone' control +; is turned off. +; Workaround for (some?) Asus eeepc desktops with Intel NM10/ICH7 Audio Controller ; ; See analog-output.conf.common for an explanation on the directives @@ -85,8 +87,8 @@ ; This profile path is intended to control the speaker, let's mute headphones ; else there will be a spike when plugging in headphones [Element Headphone] -switch = off -volume = off +switch = mute +volume = zero [Element Headphone2] switch = off Together with an eeepc.conf alsa-mixer profile set that selects this configuration instead of paths/analog-output-speaker.conf and udev rules that select the eeepc.conf profile set I get an acceptable workaround for my EeePCs. > > My test shows that with "switch=mute", I can toggle the mute-state of > > speaker and headphones independently. Unmuting the speaker does not > > unmute the headphones and vice versa. > How did you test? Since the Headphone element mutes both headphones and > speakers, you can't mute headphones independently from speakers. If you > mean that you can mute the sink in pulseaudio while using headphones, > and the sink gets automatically unmuted when you switch to the speaker > port, that's because PulseAudio stores the sink mute status separately > for the two ports and the alsa mixer gets updated during a port switch. With the above patch: after plugging in headphones, sound is in the headphones and the internal speaker is muted. In the pulseaudio mixer, I open the tab Output. There, I can select the active Port from a drop down list with the options Speaker and Headphones. Changing the volume or muting in the GUI elements below affects the active port only: * If I switch the active port to speaker, I can unmute the speaker and control the volume. Now, both headphones and speakers emit audible sound. * If I switch the active port to headphones, I can mute the headphones. This does *not* change the speaker setting in my case: Despite the headphones plugged in, the speaker emits sound at the previous volume and the headphone is mute. Generally, while I can only change one output port at a time with the pulseaudio mixer, these changes do not affect the other output port. I can hear the spike in speaker-sound mentioned in the commit message to https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=22aac4e9fdb3786178f7815a0cb2150f588b1582 but this is IMO less severe than no sound at all from the internal speaker.
