I noticed that, when I set the user to join a room already muted, there is no display of the message informing user that he is currently muted. So I thought it would be simple enough calling
api.executeCommand('toggleAudio') twice, but I noticed that it somehow only get executed once.
So for this to work I need to have a way to wait the first execution finish before calling the second command.
Does anyone knows a way to “promisify”
The muted indicator changes, doesn’t it?
That would leave you muted, if you run it twice that is.
Unfortunately that’s not possible without some nontrivial refactoring.
WHat is it exactly you need? Maybe there is another way to go about it…
I want to unmute and then mute the user. Running
api.executeCommand('toggleAudio') 2 times I noticed that, in the end, it doesn’t really execute it twice, so if I start my meeting muted, at the end, I’ll be just unmuted.
What I did so far was calling the first time, set a
setTimeout with 25ms delay and then call the executeCommand again. With this it works, but if there is a way for me to accomplish this without the setTimeout it would be better
Why do you need to unmute and mute again?
@damencho Because we noticed that, when you start a call with
startWithAudioMuted: true, the user doesn’t receive that popup telling him he is mute when he starts talking. This is only achieved by toggling mute twice. That way the popup displays normally
That sound like a bug that needs to be fixed.
Create an issue on github in jitsi-meet for this one.
I have not, I’ll try this
I think this is a limitation we don’t want to fix.
The reason why it doesn’t work in that case is that we don’t create the audio track at all, so we can’t detect if the user is speaking or not. If we create it then it’ll be added to the meeting, even though muted, which is Bad News ™ for 500 participant meetings.