[alsa-devel] [pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness

[Glenn Golden]

David Henningsson <david.henningsson at canonical.com> [2015-05-11 14:56:45 +0200]:
> 
> 
> On 2015-05-07 02:15, Glenn Golden wrote:
> >  8.  ...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.
 =============================================================================