David Henningsson david.henningsson@canonical.com [2015-05-11 14:56:45 +0200]:
On 2015-05-07 02:15, Glenn Golden wrote:
- ...because [Alsa? Pulseaudio?] maintains two independent mixer mute state variables -- one for headphone port, one for speaker port -- the semantics of both the mute key and the mute LED become less straightforward than with the hardware-based mute in 3.18.
The mute LED follows the state of ALSA's "Master Playback Switch". When that one is off, neither 3.5 mm headphone nor internal speakers have output - they're both muted.
PulseAudio's abstraction layer sets "Master Playback Switch" according to its active port's mute state. PulseAudio's active port (here speaker or headphone) will, by default, change automatically as headphones are plugged in or unplugged.
Thanks, David. I updated #7 and #8 per your comments above:
============================================================================= 7. If you elect to have the mute key toggle the Master Playback mute via an event which invokes pactl/pacmd/amixer/[insert fave mixer control tool] then the mute LED will automatically follow the Master Playback mute state as mentioned above, thus no explicit action is required to make the LED work. But! ...
8. ...if you also use PulseAudio, then the situation becomes a little more complicated, because PA maintains two independent mixer mute state variables, one for the headphone port, one for the speaker port, and the following caveats apply:
* The mute key (via your userspace mixer control event handler) will toggle only the port (HPH or SPKR) that happens to be active at that time, and will have no effect on the mute state of the other port.
* PulseAudio forces the Master Playback mute state to follow the mute state of its curently active port, hence...
* ...the mute LED will likewise follow the mute state of PA's active port via kernel auto-synch (as described in (5) above).
Taken together, these imply that when PulseAudio is in the picture, no unequivocal semantic can be attached to "mute LED on", as it was with hardware-based mute in 3.18: All you can say is that if the LED is on, then PulseAudio's active port is muted via the mixer; the LED gives no information about the inactive port's mute state. One possibly surprising consequence of this is that if the ALSA 'auto-mute' feature is enabled, then the mute LED may (or may not) change state simply by the action of plugging or unplugging the headphones, since doing so automatically switches the active port. =============================================================================