The update capture state algorithm needs refinement

[jan-ivar]

To implement the update capture state algorithm given active=true, we see a UA that implements a policy of pausing all input sources of a kind in response to UI is expected to reverse a previous UI pausing. This culminates in:

1. Let newMutedState be true if active is false and false otherwise.
2. For each MediaStreamTrack whose source is of type captureKind, queue a task to set a track’s muted state to newMutedState.

But this setting of newMutedState to false might conflict with other implementation-defined reasons the UA may have muted a particular source, like "a physical mute button on the microphone, the user closing a laptop lid with an embedded camera".

We should amend it to allow UAs to leave such sources muted. A track can be muted both by UI and physical reasons, and we should only fire unmute when it is neither.

[youennf]

Good point, unmute is somehow error-prone from the point of view of the UA, so I wonder what the error handling should be.
There are various possibilities:

1. Reject the request as the current spec allows it.
2. Unmute only the tracks it can unmute and keep the other tracks muted
3. Unmute all tracks but end capture for the tracks it cannot unmute (in a sense, it failed starting capture).

[jan-ivar]

I hesitate calling it an "error". In my mind, we're unchecking ✅ Mute all not implementing Unmute all.

I think 2 is the only interoperable option. Example (UA1 implements a pause policy, UA2 doesn't):

• The user is transmitting from two mics A and B, but has turned B off using a physical button on B
  • States: Both tracks are enabled but trackB is muted, so the audience only hears A (and silence from B)
• The user needs a bio-break and checks ✅ Mute all in the app which sets enabled = false on both tracks and calls setMicrophoneActive(false)
  • States in UA1: Both tracks have enabled = false and both tracks are muted; audience hears silence
  • States in UA2: Both tracks have enabled = false but only trackB is muted; audience hears silence
• The user comes back and unchecks ☐ Mute all in the app which sets enabled = true on both tracks and calls setMicrophoneActive(true)
  • States: Both tracks are enabled but trackB is muted, so the audience only hears A (and silence from B)

Importantly, the states are the same before and after the bio-break, regardless of UA. This seems interoperable, safe, unsurprising, and useful.

In contrast, 1 would fail setMicrophoneActive(true) and leave both tracks muted in UA1 but not UA2, and 3 would end trackB in UA1 but not UA2, which seems undesirable.