Show when peers are muted

[griffobeid]

On the UI we should show when peers are muted

[jp-systango]

Hi @griffobeid. I can work on this under some guidance. If that is ok, please assign this to me.

[griffobeid]

For sure @jp-systango !

[jp-systango]

Hi @griffobeid! I had a look at the code.

I tried by modifying the this line to this:

<h4 class="floating-name">{format!("{} - {}", self.mic_enabled, key.clone())}</h4>

to check the effect of

self.mic_enabled

on the mute/unmute button click.

What I observed is that, when I click the mute/unmute button, it changes the text for all the other attendants and on the same window. Now I thought of checking the other windows but it doesn't update there - which is expected because it is essentially a different UI in different browser/window and we haven't propagated the change yet.

So, I need to do this in two steps:

1. It should not update the text for other attendants on the same window.
2. It should propagate the mute/unmute event of one participant to other participants(other browser instances/windows) - via backend.

Does this analysis looks right? If yes then I would do a more targeted analysis on both the steps.

[ronen]

Chiming in here...

1. It should not update the text for other attendants on the same window.
2. It should propagate the mute/unmute event of one participant to other participants(other browser instances/windows) - via backend.

Does this analysis looks right? If yes then I would do a more targeted analysis on both the steps.

Yes, for 1. each "peer" would need its own indication of whether that participant has muted. And yes, for 2. right now the mute event is not propagated to the other participants so there's no way to detect when a peer has muted.

I guess an expedient fix would be something along the lines of adding a new packet MediaType for mute on/off to be sent to the backend, that for each participant would be detected by the decoder, which could then trigger a new callback along the lines of on_audio_mute(peer_id, status), which could then be acted on by Attendants to update the HTML appropriately.

See also a broader discussion in #140 -- personally I'd be in favor of taking the opportunity to start migrating in the direction of some of the ideas there (no surprise :), but of course that'd be a bigger change.