You are not logged in.
So something is intercepting keypresses from the XF86AudioMute button and setting Master accordingly (I'm using ALSA).
In my window manager config, I have XF86AudioMute bound to the following hefty command:
vol=$(aumix -w q | sed 's/pcm [0-9]*, //'); if [ $vol = 0 ]; then aumix -w $(cat ~/.aumix-vol); else echo $vol > ~/.aumix-vol; aumix -w 0; fi
Basically: if the volume is 0, it attempts to restore it from a file saved in my home dir; otherwise, it saves the volume to that file and then sets it to 0. Simple toggling functionality.
The problem is that something else is intercepting XF86AudioMute before it reaches my command and using it to set Master rather than PCM. I'd be okay with that, were it not for the fact that [un]muting Master makes the built-in speakers turn back on even if my headphones are plugged in (this is bad).
That being said, does anyone know what process/daemon/whatever could be the culprit?
Last edited by Peasantoid (2009-05-22 02:58:55)
Offline
/me sighs at length
Okay, duh, I should've seen this one coming. The problem was pommed. I just commented out the entire "audio" section in /etc/pommed.conf.
And of course I post this thread right before I find the solution...
# Actually, this solution has problems, in that pommed just uses the defaults anyway. Better fix: set the "volume", "speakers", and "headphones" options to something useless like "none".
Last edited by Peasantoid (2009-05-22 03:07:31)
Offline
As a side note, can't you more easily implement muting/unmuting PCM with "amixer sset PCM toggle"?
Offline
As a side note, can't you more easily implement muting/unmuting PCM with "amixer sset PCM toggle"?
Eh... no. Nothing happens. And when I say "nothing", well... that's what I mean. Even the return code is 0.
# Now it does. Go figure.
Last edited by Peasantoid (2009-05-22 04:03:33)
Offline