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

feat: separate API for enabled and muted states #72

Merged
merged 3 commits into from
Mar 12, 2024
Merged

Conversation

brycetham
Copy link
Contributor

@brycetham brycetham commented Feb 28, 2024

This PR updates the mute events and getters to make it clear whether the user muted the stream or the system muted the stream as part of SPARK-493485. The main changes are:

Stream:

  • Remove event MuteStateChange. This will be replaced with new events in LocalStream/RemoteStream.

LocalStream:

  • Add event UserMuteStateChange, emits a boolean with the new user mute state.
  • Add event SystemMuteStateChange, emits a boolean with the new system mute state.
  • Getters userMuted/systemMuted
  • muted will be in LocalStream only, gets the overall mute state (taking into consideration both userMuted and systemMuted)

RemoteStream:

  • Add event MediaStateChange, emits either "started" or "stopped".
  • Remove getter muted and replace with getter mediaState, returns "started" or "stopped".

@@ -5,8 +5,15 @@ export enum StreamEventNames {
Ended = 'stream-ended',
}

export enum MuteStateChangeReason {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit of a nitpick, but I wonder if we should re-phrase this as "MuteStateChangeSource" and the values be more "plain nouns" (User, Browser).

@brycetham brycetham changed the title feat: add mute reason to MuteStateChange event feat: separate API for enabled and muted states Mar 11, 2024
/**
* @inheritdoc
*/
protected addTrackHandlers(track: MediaStreamTrack): void {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what happens when RemoteStream.replaceTrack() is called and the previous track was muted, but the new one isn't. Should we emit the MediaStateChange event?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no "mute" for remote (something we're trying to correct with new vocabulary), but I think this point still stands in that the media states could differ...maybe we need to compare the old and new states at replacement time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. Yeah, I think we should.

bbaldino
bbaldino previously approved these changes Mar 11, 2024
Copy link
Collaborator

@bbaldino bbaldino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, but let's figure out @marcin-bazyl 's question

@brycetham brycetham merged commit f4ce41d into main Mar 12, 2024
1 check passed
@brycetham brycetham deleted the btham/mute_reason branch March 12, 2024 18:03
bbaldino pushed a commit that referenced this pull request Mar 12, 2024
# [2.6.0](v2.5.0...v2.6.0) (2024-03-12)

### Features

* separate API for enabled and muted states ([#72](#72)) ([f4ce41d](f4ce41d))
marcin-bazyl added a commit that referenced this pull request Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants