Not able to Screen Share with Audio only (without having a webcam)

[menace102]

---

name: Bug report
about: Create a report to help us improve
title: 'Screen Sharing not working simultaneously with audio'
labels: ''
assignees: ''

---

Describe the bug
In 1 on 1 calls, I am unable to use screen sharing while also using the same call to talk to the other person. I am unable to use screen sharing at all in group calls.

To Reproduce
Steps to reproduce the behavior:
I have been able to reproduce the error in the snap --edge install, running from source on v0.1.17, master, and develop.

For 1 on 1 calling:

1. Start a call using "Start Screen Share"
2. Select window I want to screen share (All options reproduce the behavior)
3. The person being called receives the call immediately and is able to see the screen. The caller doesn't join the call until about 30 seconds later and the call screen is shown.
4. If I change nothing at this point, the called person is able to see screen, but no audio from either side. The call screen tells me to unmute in order to start talking.
5. If I click the unmute button, screen sharing turns off but audio now works.

Additionally, I cannot start screen sharing from inside the call. The option tells me my browser is incompatible and prompts me to download teams.exe.

For channel calling:

1. Start channel call (there is no option to start a channel call with screen sharing)
2. Screen sharing option is greyed out.

Expected behavior
I am expecting to have screen sharing to work with audio in both 1 on 1 and group calls.

Screenshots
Let me know what you'd like screen shots of. I am unsure what to grab that will be useful to you.

Desktop (please complete the following information):

• OS: Ubuntu 18.04
• Installation package: snap, from source, deb
• Version: v0.1.17, master, develop

Additional context

1. Am I doing something wrong?
2. How are you using screen sharing?
3. Does screen sharing work in channel calls?
4. Are there potentially any dependency differences I may be running in to?

[IsmaelMartinez]

Hi,

I am not personally using screen sharing much, but helped with the implementation. Direct screen sharing seems to take a long time to start but starting a call and the screen sharing seems ok.

Have you tried starting the call (audio or video) and then doing the sharing?

Some people have reported low quality on some screen sharing with one on one, but not what you are reporting. Also the slow delay on the start of direct screen sharing.

Can you edit your report as from the bug template?
https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/.github/ISSUE_TEMPLATE/bug_report.md

Having the type of installation you are using, steps to reproduce, etc? Eases the process of narrowing down the issue.

If call and share works, that could be the best compromise as MS have mention they are implementing screen sharing for Chrome so any work we do here on that area might be obsolete or need redone after that.

Hope helps

[menace102]

Thank you for the quick response! I have updated. I wasn't sure if this was a bug or me using it wrong, so I wasn't sure how to format.

How do I start the call and then share my screen? The option through Teams is greyed out, telling me it's not yet supported, and I can't click the "start screen share" button anymore. Am I missing something?

[IsmaelMartinez]

Normally, when you start a call, the grey out button becomes available after around 3 seconds.

I have seen the odd case when the button stays grey out. The temp solution is to stop the call, move to a group chat (or a different one) and move back.

Again, I will have been looking into that if MS wasn't planning to add support to all of this "soon".

Can you try that and see if it works?

Also, might be wise to clean the ~/.config/teams-for-linux folder

[menace102]

Ahh, I see. Unfortunately, it doesn't seem to exhibit that behavior.

My current set up is running yarn start after a git checkout of v0.1.17.

I deleted everything in the ~/.config/teams-for-linux and restarted the app with no change in behavior.

Running nodejs --version gives me 8.15.2. Unfortunately, I can't find out what version of Teams we are using..

[IsmaelMartinez]

if running from source, the "config" history is under ~/.config/Electron

I will probably recommend using the develop branch, as it is the latest.

[menace102]

Still, the button never makes itself available. I don't know if it's important to mention that I don't have a camera? I also found the Teams Version from the mobile app.

Version: 1416/1.0.0.2019031802
Calling Version: 2019.07.01.4

I am now using develop, and I deleted everything in ~/.config/Electron, and restarted the app.

After a yarn run

yarn run v1.15.2
$ yarn install && electron ./app
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
$ electron-builder install-app-deps
Configuring yargs through package.json is deprecated and will be removed in the next major release, please use the JS API instead.
Configuring yargs through package.json is deprecated and will be removed in the next major release, please use the JS API instead.
• electron-builder version=20.39.0
• loaded configuration file=package.json ("build" field)
• rebuilding native production dependencies platform=linux arch=x64
• rebuilding native dependency name=spellchecker

[IsmaelMartinez]

The button for one-to-one calls is the 📞 icon.

I can see it does mute the mic (not sure why). It does the same with the video, but no audio, in the video calls.

Unfortunately I got no time to test/fix this at the moment, so it might need to wait a couple of months. I will add the "help wanted" to see if someone else can help.

The yarn logs look ok, the deprecated warning are from dependencies that we are using and should not affect us.

The teams version that we are using is just the same as you get in the chromium/firefox browser, but with a few tweaks.

If you got the time, you can try opening the chrome developer tools (start with --webDebug or click Ctrl+Shift+I) and try playing with the tweaks that are in here:
https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/app/browser/index.js#L41

from the console, you can try to get either:

angular.element(document).injector().get('settingsService').appConfig
angular.element(document).injector().get('callingSupportService')

The list is pretty long...

[menace102]

That is the button I use to start the call. Once I am in the call, how should I start screen sharing? The button I'm trying to use is after I start the call, there is a button next to the mute mic button that tells me my browser isn't supported for screen sharing. Are we referring to the same thing?

Sounds good. Thank you so much for the awesome work you're already doing on this.

I'll see what I can do. This isn't the type of developing I'm used to, so I'm not sure I'll get anywhere.

To be clear, you do see the expected behavior when you do screen sharing, at least with 1 on 1 calling?

[IsmaelMartinez]

I see the mic getting mute, and the "screensharing" button only gets available after the call is accepted.

Then, I can share the screen with mic if I enable the mic 1st and then I click on the screen share. Hope helps

[IsmaelMartinez]

ok, sounds silly but have you try checking that you mic is not muted? I have added extra tweaks that might help on this but might. I will close it and release it in 0.2.0 (just next) as I can see it working just fine in my environment. Do re-open if you still got the issue.

[menace102]

I finally had a chance to test this out. Unfortunately, it doesn't look like much has improved.

How should I ensure mic is unmuted? It is unmuted in system settings. Is there an Electron setting or something that I can ensure it is unmuted there too?

I'm still not seeing the screen share button become available after initiating a normal call.

[IsmaelMartinez]

I think this is the same as #64 . Also, I think is same as #106

Can you try with the argument explain in there? (using another "desktop" in the starting arguments)

[IsmaelMartinez]

The argument is this one. Could you try?

#35 (comment)

[menace102]

Unfortunately, I don't think it did anything.

Steps taken:

1. I'm using the Snap installed version.
2. I modified the Desktop Entry in /var/lib/snapd/desktop/applications/teams-for-linux_teams-for-linux.desktop, in the Exec line to:
   env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/teams-for-linux_teams-for-linux.desktop XDG_CURRENT_DESKTOP=Unity /snap/bin/teams-for-linux
3. Restarted application and no change. I created a test 1 on 1 call, waited a few seconds, and the screen sharing option still prompts me to download Teams. I also tried changing windows multiple times and waited a few seconds after each.

Let me know if I did that right.

[menace102]

Deleting everything in ~/.config/teams-for-linux didn't change anything either.

[IsmaelMartinez]

Unfortunately, I don't think it did anything.

Steps taken:

1. I'm using the Snap installed version.
2. I modified the Desktop Entry in /var/lib/snapd/desktop/applications/teams-for-linux_teams-for-linux.desktop, in the Exec line to:
   env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/teams-for-linux_teams-for-linux.desktop XDG_CURRENT_DESKTOP=Unity /snap/bin/teams-for-linux
3. Restarted application and no change. I created a test 1 on 1 call, waited a few seconds, and the screen sharing option still prompts me to download Teams. I also tried changing windows multiple times and waited a few seconds after each.

Let me know if I did that right.

The process seems right. I will prefer using the deb package only because our snap is still under development...

Did you try:

• Starting a 1-on-1 call with audio.
• once the call is already on, and you can hear each other, then start the screen-share?

Apologies, this is a pretty odd one as no many people are suffering this.

[IsmaelMartinez]

or maybe try reconfiguring the pulseaudio like in here #117 (comment)

[IsmaelMartinez]

did you try all the stuff in my previous comments?

[menace102]

did you try all the stuff in my previous comments?

I'm unsure which one you're referring to, so I'll address each one. Sorry for not addressing earlier.

The process seems right. I will prefer using the deb package only because our snap is still under development...

Did you try:

• Starting a 1-on-1 call with audio.
• once the call is already on, and you can hear each other, then start the screen-share?

Apologies, this is a pretty odd one as no many people are suffering this.

This is what I've been testing lately. Screen sharing button remained greyed out with a prompt to download Teams.

and, or checking the "settings" for the call and see that MS is not picking something else for the audio. Hope helps but this starts to smell more like a system configuration issue rather than a client issue.

apologies, but the Linux ecosystem can be a bit of a maze in order to get things working with all configurations.

I am able to make calls and have audio in other calls, so I'm not sure how you'd like me to change my audio settings and have had successful meetings on it otherwise.

Something has changed recently, and I can't screen share using the Start Sharing Your Screen button on the chat screen. =[

[IsmaelMartinez]

Have you tried that with a Deb package?

[m27315]

@IsmaelMartinez, where are deb packages posted for the latest release, v0.2.0, or should we build them ourselves?

[IsmaelMartinez]

Hi,

The deb package is under here:
https://github.com/IsmaelMartinez/teams-for-linux/releases/tag/v0.2.0

it was strange as it was appearing today as a "draft" release but I am really certain it was fully release a few weeks ago.

Apologies for that.

[menace102]

I uninstalled everything and installed using the .deb. Nothing seems to have changed. I'll have more time to more thoroughly test on Monday.

I was able to download from that tag yesterday, for whatever that's worth.

[IsmaelMartinez]

Another option is to see what package dependencies you got and see if you can re-configure them (or reinstall)

for dpkg you can just run dpkg --info teams-for-linux_0.2.0_amd64.deb | grep Depends

[menace102]

Depends: gconf2, gconf-service, libnotify4, libappindicator1, libxtst6, libnss3, libxss1

That's what I got. Unsure if it's helpful.

[IsmaelMartinez]

can you try to reconfigure gconf2 and/or gconf-service? they might have got themself a bit "broken"

[menace102]

I ran sudo dpkg-reconfigure gconf2 gconf-service and received no output.

I restarted the app and no change in behavior. Do I need to reinstall?

[IsmaelMartinez]

maybe, give it a try and see if it works. Sorry for not been more helpful, it is a pretty odd issue the one that you are having.

[menace102]

I uninstalled, reran dpkg-reconfigure, and then installed. I also removed everything in ~/.config/teams-for-linux. Nothing has changed. Do I need to try and get an external camera?

[IsmaelMartinez]

Maybe try a VM with a fresh install? If the VM works then is a system configuration issue. Getting hardware is always more difficult/expensive and normally doesn't provide conclusive answers.

[menace102]

I just used VirtualBox on a fresh 18.04.2 install using v0.2.0 from .deb of teams-for-linux.

Exact same behavior. =[

[IsmaelMartinez]

Maybe try the edge channel from snap (the one that @julian-alarcon just build yesterday) and see if that improves your case.

Otherwise, see if you can borrow a camera to test if that is the case. Pretty odd.

[menace102]

I've had some more weird behavior.

Note: I uninstalled previous versions before installing the new one.

I was using the .deb 0.2.0 and plugged in a camera, which worked out of the box. Screen sharing via the "Start Sharing your screen button" is working again, but no change in other behavior, specifically no screen sharing after starting a 1 on 1 call with someone (with or without camera).

I then installed the one from the Ubuntu Software Center, looks like it was 0.2.1 and I was unable to get the camera to connect and also no change in screen sharing.

I then installed the snap --edge version, and same thing.

I reinstalled .deb 0.2.0 and camera works out of the box, "chat screen sharing" works.

I know that's not particularly helpful.. Is there any settings I should grab

[IsmaelMartinez]

I have seen some cases where the screen sharing doesn't appear in the 1st chat you got open. Moving to another group/person and back sorts that out. I suspect is some timing issue.

The Ubuntu software one is snap, so you need to activate the camera (see the known issues/how-to)

So, just to resume, you need a camera to be able to screen share?? But if you got a camera, it works? F Taht s the case... It might just be wise to put it n the known issues section.

[menace102]

I've tried the moving thing. I've made sure I did it every time I've tested as well, and no luck.

I have a camera, but still cannot screenshare, unfortunately.

[IsmaelMartinez]

Are you waiting long enough for teh one-2-one sharing?it take about 30 seconds to start the sharing (no idea why)

[menace102]

Sorry, I should clarify..

I can screen share using the second button from the right. It starts a "call" and after approximately 30 seconds, my screen appears on the other side of the "call. I cannot get audio to work while continuing to share my screen. Sometimes, I'll get a prompt that says "Unmute to start talking". I press unmute, audio immediately starts working, but the callee can no longer see my screen.

What I can not do is be in a call and start screen sharing. This button is greyed out. This never makes itself available. I've tried waiting a few minutes, swapped to other chats to try and refresh, and with or without a camera attached.

[menace102]

From what I can tell, this application works by pretending to be a web client on Windows? Or does it try to pretend to be the Windows Desktop client?

I did some testing with Teams in Windows 10 on both the Edge browser and Chrome. And screen sharing is not enabled for me there either. (Note, it did work in the native Windows client) Is that expected behavior?

I'm starting to wonder if it's potentially something that needs to be configured on the Admin side of IT? I don't know...

[julian-alarcon]

Hi @menace102 . Teams for Linux uses Electron framework, that is build on top of Nodejs, that is build in top of Chromium. So, it pretends to be the web client. The screensharing feature was a collection of inverse engineering of the behaviour of the official Addon https://chrome.google.com/webstore/detail/microsoft-teams-screen-sh/dhheiegalgcabbcobinipgmhepkkeidk?hl=en

[menace102]

Thanks for the info!

I'm trying to isolate the problem from Teams for Linux and our particular Teams setup within my organization.

It sounds like the next thing I need to try is to install that Chrome extension on my Windows machine and see if screen sharing from within a call works. If that doesn't work, then the logical conclusion would be something that our IT has done? Is that correct?

If it does work, then I need to continue debugging on this side?

[IsmaelMartinez]

Seems like a good test to confirm the chrome extension works, but I think that should just work on Linux (add the windows variable if it doesn't work on Linux).

I will try older versions and see if any of them work. Probably start from 0.1.16 and make your way up creating a table with what works and what doesn't. Maybe the additions from 0.2.0 made it a bit worse for you... even if they where mean to help.

[IsmaelMartinez]

I am closing this due inactivity. It also does look like is outside of our development control . Ping if you want it reopened.

[menace102]

Thank you guys for your patience on this one. Sorry I haven't had time to test.

After some discussion internally, turns out some level of settings at the management/IT side of things can break it for me. I'm unsure what they changed, but it's all working now.

[IsmaelMartinez]

Video conf needs few things open... Firewalls setup and blocking UDP might be stopping you from been able to use it. Glad to heard it now works. Hopefully you can get more info about what they did to fix it!! (probably relaxing some firewall rules)