Can’t share screen when starting with audio only mode

[ramrami]

Description

---

When I start a call with audio only mode (startAudioOnly:true in configOverwrite), I can’t share my screen. I can see an error in the console that says “No screensharing in audio only mode”

But if I enable the video then disable it, the screen sharing start working.

Current behavior

---

Can’t share screen when starting with audio only mode, except if I enable then disable the video.

Expected Behavior

---

Screen sharing should also work when starting with audio only. Without enabling the video.

Steps to reproduce

---

Use JitsiMeetExternalAPI with startAudioOnly:true in configOverwrite

Environment details

---

Server: https://meet.jit.si
Browser: Chrome Version 81.0.4044.138 on MacOs

[ramrami]

I think I found a workaround for this bug: setting startAudioOnly: false and startWithVideoMuted: true in configOverwrite

[jallamsetty1]

We do not support sharing of screen when the client is in audio-only mode. This is per design not a bug. If you want the ability to share the screen, please use the startWithVideoMuted flag as suggested above.

[OleksiiChernomaz]

to be frank configuration option and its behaviour does not sound logically from the first look and i also was initially confused by this behaviour. This is a very strange "design", which feels like a bug and looks like a bug or broken by design or smth like a terrible hack. e.g set "startAudioOnly:true" to get changes of ... performance settings of the call and by this indirectly shut down video stream (oO)

Reason why this setting in general super confusing that it's mentioned in the context of "how to disable camera by default"

1/ its broken from logical point of view
As a result this setting actually does a change in the "performance settings" to "best performance". From developer point of view, this is the last thing which you might expect because performance/quality is one thing and deactivation video streaming is completely different thing. "Quality" can affect bitrate of the audio channel / framerate of the video stream. Last thing which you might expect if that "performance" will disable for you possibility to share screen or use camera or receive this streams and not only for you (as a source of stream), BUT for all participants in the call (who are recipients in our case) until all of the parties change the setting. When you change "performance" you expect changes in the bitrates and change in the quality of the audio/video, but not deactivation. Yes, edge case of bad connection might be very low framerates, which can lead to <1 fps for video and kilobytes for audio channel, BUT not missing them completely. Thereby from logical point of view this is "broken by design" because in our case we stupidly throw away stream and provide is a "given".

2/ this setting is broken from UX point of view
If you take a look at this issue from another angle: from UX point of view. Someone wants to start call with disabled camera. It does not mean that this person wants to sacrifice quality of the audio call or would never want to share screens: this person just wants to get the camera disabled, nothing else. Maybe i want to have HD quality for audio and use all my channel for receive/sending audio channel. But there no any option/config which allows to disable camera (you can either disable all or nothing). Now lets think about expectable application behaviour. Take any system / OS. There always separation with permissions:

• camera resource access (on/off)
• audio input resource access (on/off)
• screen capturing access (on/off)
• optionally can be "quality" (bitrates or other units, but it does not overlap anyhow with permissions or access to resources, but rather a preference how "wide" is your internet channel and how much you want to use it)

we talk here that if application wants to access particular resource, there must be granted separately permission for each of the sources. Similar made in Teams, Zoom or others. They never mix up performance with blocking access to particular resource. Jitsi app is probably one of the first apps, where i see that all those things in the configuration were mixed up into 1 config option, which at the end leads to a change in the "performance" and then claims that it's a good design and not broken at all. If i want to enable screen sharing, it does not mean that i want to be able to use camera, etc..

3/ its broken from security point of view
use of "startAudioOnly:true", this is what was recommended by support as well in context of the data protection topics to avoid accidental camera activation during the calls (when call starts). BUT If person decides to share screen, then must be changed... yes, "performance setting"! and not only by someone who shares, but also by all the parties in the call who needs to see shared screen. What issue it might cause? yes, someone accidentally can also enable video stream as well from the camera. Is it safe? not at all. Person in the particular call wants only to receive a screen sharing stream or video stream from someone else, BUT because of the change in the settings of performance it unlocks also a possibility to use a camera (surprise surprise).

This issue was raised few years ago and surprisingly since then nothing has changed.
And yes, i understand that product is powered by community, so on or rather evolves by a good will than has a serious development plans. But protecting things which are broken by design, imo, it's also not the best idea. Because one of the key points of the tool is "More secure, more flexible...". It does not sound more secure even based on the last example i've provided, when mixed things in the configurations at the end can lead to undesired behaviours to all who uses this tool.

[jallamsetty1]

This issue was raised few years ago and what is interesting since then nothing changed.
And yes, i understand that product is powered by community, so on or rather evolves by a good will than has a serious development plans. But protecting things which are broken by design, imo, it's also not the best idea. Because one of the key points of the tool is "More secure, more flexible...". It does not sound more secure even based on the last example i've provided, when mixed things in the configurations at the end can lead to undesired behaviours to all who uses this tool.

@OleksiiChernomaz, have you tried the latest client before going on a lengthy tirade here about how we have a broken system. This issue is 3 years old and a lot of changes have been made since then.

• You should be able to turn on your camera or start a screenshare even you start the call in audio-only mode.
• Starting a screenshare when in audio-only mode doesn't turn on the camera automatically.

[OleksiiChernomaz]

we use one of the latest versions, but i did not notice any differences. Same behaviour as i explained and same as written in the docs (i added a link in prev comment). Can you propose better way how to disable cameras by default, but keep independent quality settings and keep possibility to share screen WITHOUT change in the performance settings? I would be happy to hear how to do it.

[jallamsetty1]

The link that you referenced is not official Jitsi documentation. Please refer the handbook or config.js for this. By using startWithVideoMuted: true or startVideoMuted: n, you can start the conference with camera disabled. The user should be able to enable their camera or start a screenshare anytime without having to change their performance settings.

[OleksiiChernomaz]

this sounds super promising. I do forward it to the team to check it and if works, you made my day. Because so far main point was from guys who set it up that thats the only option and all the rest did not fit. This how i found this thread and docs listed with setup ;) will keep u posted if works or if there were issues with setup