Chrome Users Must Allow "Sound" to Talk

I’m working with a developer to integrate Jitsi into a custom app/program. We’ve noted that, for some reason, Chrome users must go into their permissions and set “Sound” to Allow, then refresh the page, in order to talk (see image). Before doing that, they can hear, but they cannot talk.

However, this doesn’t happen at Where in the code (lib jitsi meet maybe?) can we look to see what’s going on with this and see how to fix it?


Normally when getUserMedia asks for accessing video and audio the browser is the one asking the user for those permissions, there is no special code for handling that.

I assume it has something to do with chromes autoplay policy: Autoplay Policy Changes  |  Web  |  Google Developers

But this is just a shot in the dark

@damencho: If Fuzzyma is correct, how did you guys get around this on

By using pre-join screen

@damencho: I don’t understand your reply. Here’s what’s happening…

1.) First time Chrome user joins and allows mic. and camera permissions.
2.) The user can hear everything, but others cannot hear them.
3.) They then need to go into permissions and set Sounds to Allow (not Automatic (default)).
4.) They still cannot be heard.
5.) They refresh the page, and now they can be heard.

Can you guide us on this please?

I’m not sure why is this happening if the user had already allowed mic and camera permissions… and why sound permissions will affect mic permissions. Have you tried just reloading the page after giving mic and camera permissions? Does that solve the issue?
Have you tried on your deployment with jitsi-meet app?

A custom volume slider was added by the developer which altered the “gain” for the mic. in order to change the mic. volume level. We disabled that and it seems to have resolved the issue, but more testing is needed.

Question: Does Jitsi have a direct way of increasing/decreasing the audio input levels?

Nope, there is no such feature