Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show when peers are muted #106

Open
griffobeid opened this issue Jul 17, 2023 · 4 comments
Open

Show when peers are muted #106

griffobeid opened this issue Jul 17, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@griffobeid
Copy link
Contributor

On the UI we should show when peers are muted

@griffobeid griffobeid added enhancement New feature or request good first issue Good for newcomers labels Jul 17, 2023
@jp-systango
Copy link

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

@griffobeid
Copy link
Contributor Author

For sure @jp-systango !

@jp-systango
Copy link

jp-systango commented Sep 13, 2023

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
Copy link
Collaborator

ronen commented Sep 13, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants