A short Q&A from a YouTube video explaining three ways to mute audio in WebRTC: (1) set an audio track's enabled attribute to false — the browser sends silence (low bitrate) but doesn't automatically trigger DTX; (2) use replaceTrack to detach the track from the PeerConnection — stops sending packets and reduces packets-per-second; (3) stop the track and call getUserMedia again when needed — has privacy advantages but can error, adds latency, and breaks voice-activity/speech-detection features. The speakers recommend starting with method (1), move to (2) if needed, and consider (3) only if necessary due to complexity and edge cases.
We're here with another question, and this time, how do you mute audio in WebRTC?
So for that we have three different ways to go about it. First one is the easiest one. You just get the audio tracks enabled attribute and set it to false. That will cause the browser to send silence, which encodes relatively well. So you're sending 50 packets per second with a very low bit rate.
Okay, but it might also be dtx, Right? Discontinuous transmission.
It doesn't automatically trigger dtx, which is a bit sad, but we never got around to specifying that behavior.
Okay.
The second way is to use replace track to actually detach the track from the peer connection, which will stop sending packets, which, if you are looking at packets per second, is good for your server side. And the third alternative is to actually stop the track and then call getusermedia again when you want to speak again. But that has a couple of problems. The first one is you need to call getusermedia again, which might error, and that has latency. So you need to get that right in the user experience. Experience. And the other issue is that doing something like speaking minute detection no longer works.
Yeah, because.
Privacy advantages, but yes.
Okay, so out of the three, which ones would you choose for your application?
Start with the first one, move to the second one if you have enough time to implement. Maybe consider the third one, but that's a lot more complicated.
It's complicated not because of the implementation, but because of all of the ugly edge cases.
