Re: [PATCH 0/2] Introduce Poly/Plantronics mute event support

[Takashi Iwai <tiwai@xxxxxxx>]

On Thu, 05 Dec 2024 23:19:00 +0100,
Terry Junge wrote:
> 
> On 12/3/24 10:56 PM, Takashi Iwai wrote:
> > On Wed, 04 Dec 2024 06:23:30 +0100,
> > Terry Junge wrote:
> >>
> >> On 12/2/24 11:32 PM, Takashi Iwai wrote:
> >>> On Mon, 02 Dec 2024 23:35:51 +0100,
> >>> Terry Junge wrote:
> >>>>
> >>>> On 11/25/24 12:55 AM, Takashi Iwai wrote:
> >>>>> On Sun, 24 Nov 2024 21:32:39 +0100,
> >>>>> Terry Junge wrote:
> >>>>>>
> >>>>>> Hi Jiri and Takashi,
> >>>>>>
> >>>>>> I'm not sure how it works with two different maintained trees
> >>>>>> but this patch set needs to be applied and flow upstream together.
> >>>>>>
> >>>>>> If the HID patch is applied without the ALSA patch then mute sync
> >>>>>> issues will occur with multiple Poly/Plantronics product families.
> >>>>>
> >>>>> Both patches can be applied individually, and even if only one of them
> >>>>> is applied, it won't hurt.  So I guess both subsystems can take the
> >>>>> corresponding one at any time.
> >>>>>
> >>>>
> >>>> Hi Takashi,
> >>>>
> >>>> I've tested out the behavior with each patch individually applied and
> >>>> have found that, IMHO, the mute functionality and synchronization is
> >>>> worse than the current behavior with neither patch. However, with both
> >>>> patches applied the mixer UI microphone mute control and the headset
> >>>> mute button are fully synchronized.
> >>>
> >>> That's odd.  How can it worsen?  As far as I understand from the patch
> >>> descriptions, the USB-audio patch corrects only the mixer volume
> >>> control names, while the HID patch changes the quirk to be generalized
> >>> (to be dropped the next key in a short period).  If only USB audio
> >>> patch is applied, it doesn't matter as the volume binding didn't
> >>> happen before the patch.  OTOH, ditto, if only HID patch is applied.
> >>> Am I missing anything here?
> >>
> >> The USB-audio patch also corrects the names for the mixer switch controls.
> >> The HID patch also adds mapping of the mute button to the KEY_MICMUTE event.
> >> It's not the playback volume handling that gets worse, it's the capture
> >> switch handling that gets worse.
> > 
> > That's what I don't understand -- how can it get worse?  The key
> > binding didn't work beforehand, no?  Now HID patch handles the
> > mic-mute key event, but what can it *break* without USB-audio patch?
> 
> Sorry, it's a long story...
> All this describes the behavior I see with Ubuntu 24.04.1.
> 
> 
> The current mute behavior with no patch:
> 
> Headset cannot communicate mute toggle intent to mixer
> Mixer cannot communicate mute state to headset
> 
> Due to the name of the microphone mute control a software based mute control is
> created that mutes the capture stream after it is received from the headset. It
> is toggled on/off with the UI mixer dialog. Toggling this control is not
> reflected in the headset, mute LED does not toggle, "Mute On" and "Mute Off"
> prompts do not play (on some models). This mute control is totally independent
> of the headset's mute state.
> 
> The headset also has a mute control that is toggled on/off with the headset mute
> button. It mutes the capture stream before it is sent to the host. Mute state is
> reflected in the mute LED and/or mute prompts. As the headset's mute control did
> not get bound to the mixer, this mute control is also totally independent of the
> software mute control.
> 
> If either of these mute controls are muted then the capture stream is muted.
> Only if both controls are unmuted will the capture stream be live. So if the
> user mutes with the UI mute control then they need to unmute with the UI
> control. If they mute with the headset button then they need to unmute with
> the headset button.
> 
> 
> The mute behavior with only the HID patch:
> 
> Headset can communicate mute toggle intent to mixer
> Mixer cannot communicate mute state to headset
> 
> A software mute control is created with the same characteristics as described
> above with one addition. Not only does the software mute control toggle by using
> the UI mixer dialog. It can now be toggled by the headset mute button sending the
> mic-mute key event. This mute control is no longer totally independent.
> 
> The headset mute control is still as described above with the addition of
> firing a mic-mute event when the mute button is pressed. So every press of the
> mute button toggles the headset mute state and toggles the state of the
> software mute control. This mute control is still totally independent. You can
> only toggle it with the headset mute button.
> 
> So now the following scenario is possible...
> Remember that if either control is muted the capture stream will be muted.
> 
> Mute using the UI dialog - software control is muted, headset control is not
> Press headset mute button - headset control is muted, software control is not
> Press headset mute button - software control is muted, headset control is not
> ...
> Press headset mute button - headset control is muted, software control is not
> Press headset mute button - software control is muted, headset control is not
> Unmute using the UI dialog - both software and headset controls are not muted
> Press headset mute button - both software and headset controls are muted
> Press headset mute button - both software and headset controls are not muted
> 
> So the user should not use the UI dialog to toggle microphone mute.
> 
> The mute behavior with only the USB-audio patch:
> 
> Headset cannot communicate mute toggle intent to mixer
> Mixer can communicate mute state to headset
> 
> With the names corrected the mixer now binds to the audio controls in the
> headset. A software mute control is no longer created. Toggling the mute
> control in the UI dialog actually sends the mute or unmute setting to
> the headset's feature unit. As such, the mixer is in direct control of the
> headset's mute state.
> 
> The headset mute button is not sending mic-mute events so it is unable to
> request the mixer to toggle the mute state. The headset will comply with the
> audio control mute/unmute commands as they come in. The headset's response to
> mute button presses depends on the last audio control mute command received
> from the host. If the last command was unmute then the mute button presses will
> toggle the local mute state as described in earlier paragraphs. If the last
> command was mute then the mute button presses will *not* unmute the headset.
> 
> So if the user mutes the microphone using the UI dialog, the headset will mute.
> Then pressing the headset's mute button will result in the headset playing its
> ummute prompt (beeps or "Mute Off") followed immediately by playing its mute
> prompt (beeps or "Mute On") and the headset remains muted. At this point the
> only way to unmute is by using the UI dialog.
>  
> So the user should not use the UI dialog to toggle microphone mute.
>  
> 
> The mute behavior with both patches:
> 
> Headset can communicate mute toggle intent to mixer
> Mixer can communicate mute state to headset
> 
> The microphone can be muted or unmuted by using the UI dialog or the headset's
> mute button, in any order.
> 
> 
> So...
> Neither of the single patch scenarios is actually *broken*. The user can
> mute or unmute the headset although some confusion can occur if the UI dialog
> is utilized.
> 
> So it comes down to user experience and possibility for confusion to rate them
> from best to worst.
> 
> Are either of the single patch scenarios better than or equal to the no patch
> scenario?

I don't think it'll be so big problem to apply individually.  Even if
only one of two patches is applied, it doesn't break things
seriously.  Certainly there can be inconsistency due to individual
mute behavior, but that's not much worse than the current situation,
IMO.

And, as long as we keep Cc-to-stable tag in both patches, both of them
will be taken to stable trees.  Also, since the changes aren't too
intrusive, it's no big problem to apply both patches to the same tree
by receiving Ack from the other subsystem maintainers, too.


thanks,

Takashi