Anyone here uses Teams on FreeBSD?

Nope, no audio drop so far, but im still struggling with the headset issue. Anyone here got a working combo of audio usb bluetooth adapter and bluetooth headset incl. mic which is worth to share?

Right now I’m using my Air for Teams, so moving that over to my Desktop 🖥️ (FreeBSD) would allow me to have everything in one place. 🥳
 
I have run Teams with Chromium on FreeBSD as part of work as a researcher, with varying levels of success, since 2020. In the past year plus, it has worked pretty well. In the past, audio from others would be distorted, but that was "fixed" by changing the default port options from ALSA to sndio, which I think happened in late 2020.

My best success has been with using a USB Headset with an included headphone. That way one can just do a
sysctl hw.snd.default_unit=USB_HEADSET_DEVICE_NUMBER
and things just work (audio, video, screen sharing). I have stayed away from background effects (like blur) as when I first tried them video just crashed. It may be better now, but I have been lucky enough with a generic enough background that I don't care.

On a different computer I have compiled a custom Chromium from ports that used pulseaudio so that I could select separate inputs and outputs and was able to do this using a Yeti USB microphone and an external speaker, and it worked great for a time. However, sound from my end has started to get garbled the last month or so and I haven't had time to track down where the problem is (internet connection, pulseaudio, something else). It doesn't help that setup is on a computer I don't use as often anymore. I may just go back to the "stock" Chromium from ports and set up a virtual_oss (didn't know so much about that when I went the pulseaudio route).

Regardless, there will be times when Teams will just act weird and people will immediately blame you, even if everything tests fine locally. From talking to system administrators here, I understand that sometimes you get a "bad" Teams instance for a session (maybe like a noisy neighbor VM). It's a lottery for which machine you get for a Teams meeting session based on your location, which is why disconnecting and reconnecting sometimes helps. Other times, it works better the next day. The frustrating thing is that it rarely is easy to track down when things go bad. So, I don't bother tracking things down until it becomes consistent.

I have heard from other who use Linux that they prefer to use it in Chromium/Chrome instead of the beta Teams Linux client because the Chromium client gains features quicker and appears to be more stable than the Teams Linux client.

Sorry if this doesn't answer any specific questions, but it does provide an additional data point.
 
There appears to be some kind of bug in the OSS backend for Chrome. Firefox OSS audio is much better, but Microsoft doesn't support that! I've found out that building Chrome with ALSA audio backend is more stable on FreeBSD and maybe we should consider that, because putting patches upstream chrome is very difficult!
 
hselasky@ said:
putting patches upstream chrome is very difficult!
Click to expand...
I'd call that an understatement since they outright refused to take any BSD-portability patches (which lead to a port with >1000 local patches) 🙈

Anyways, that might be the relevant hint here: I don't experience any issues with Teams in chromium (other than the sporadic reliability issues every colleague using Windows or Linux sees as well). But then, my chromium doesn't use OSS directly but SNDIO instead....
 
Yes, SNDIO works too, but having ALSA the default would be better, now that the ALSA-OSS plugin has received some needed care. Native Chromium OSS audio glitches a bit in Teams, which is annoying.

>1000 local patches
Click to expand...

I totally agree. I experience the same thing with the Linux kernel and webcamd in ports. The bugs reported "by the wrong people" are simply not counted or given priority. It's very strange.
 
Ah, I didn't know that the ALSA-OSS plugin has been updated. I may try rebuilding with ALSA to see if that is better as well.

I hope to have some time with the machine next week and hopefully I can convince someone at work to receive some calls, so I can test their experience (as I said, local recording of the call on my end is fine, but their recordings of me from their end are dreadful, and it's not just because I'm hearing my own voice 🙃 ).

I third the "would be nice" if Chromium accepted FreeBSD patches.
 
Just for the record, last Friday I experienced several audio drops during a Teams session. First drop appeared after 45 minutes in the meeting and lasted for at least 20 secs. I used my Macbook Air with Safari latest upgrade, so it seems this is not particular related to the browser or os, looks more like there is an issue on the provider side (Microsoft). The session took almost three hours and it seemed the more time went by the worse the audio drop appeared in seconds as well as in frequency. 🤷‍♂️ As I’m a vivid facetime user with my family, this experience reminds me of my skype calls before facetime had been around. So I guess there is still some skype in there somewhere. 👀
 
One thing you can also do, is to install teams in a VM and then use rdesktop to connect the audio and display.

I think these additional options should do the trick:

-r sound:remote /sound:sys:oss,format:1 /microphone:sys:oss,format:1

Many years ago I used to cross-compile Windows applications using wine under FreeBSD, but the vendors do stupid things like using 32-bit installers for 64-bit software, which screws up wine. So this is a never ending ongoing battle, to simply get things to work.

I think the reason OpenSource solutions has not yet replaced the Microsoft OS, has simply got to do with royalties given to middle men and the shops that sell Microsoft products. If a product is free, no matter what percentage you demand, the result will be zero money. This also has to do with content restriction technologies, supported by the movie industry. What the Microsoft OS allows is simply not the same like a FreeBSD power user is allowed to do. And the advice you get from the Microsoft OS certified shop is not the same like you get from a FreeBSD developer. Typically when your computer breaks down, you are asked to thrash the old one and buy a new one. Everything you need is backuped in the cloud. The other day someone by accident asked me for help and I told them to tell the Microsoft OS certified shop to explicitly take the harddisk out of the computer and give it to the owner, before the computer was trashed. Two weeks later it appeared that thousands of important files were missing from the supposedly bullet proof and OS integrated cloud backup. OMG! The Microsoft way vs the FreeBSD way really got very clear to me last week! I'm sticking with FreeBSD and what supports FreeBSD. What I really wanted to say, you might want to try audio/hpsjam instead of teams. It might not be perfect, but utilizes a different audio transport technology than what teams does. I.E. lower latency which is sometimes important when trying to get the word and say something in a heated discussion. Did you ever wonder how 100 milliseconds of delay for every sentence exchange make conversations several minutes longer than they should be in the end? Be smart and put teams in the trash, save time and tell your friends about the alternatives :) My rant for today!
 
Yes, I have run the Teams client in a Windows virtual machine in bhyve and used freerdp for conversations too. It works great for audio only conversations! Unfortunately, one can't pass through the webcam (at least not with any flags I could pass). So, it's not an option when people insist on having video (not always my choice).

Thanks for the tip on audio/hpsjam, I won't be able to get work to use that, but it's nice to try something different in non-work situations.
 
I think I have almost zeroed down upon the main cause for the audio drops. In my case it was due to being oversmart. I was using a User-Agent spoofer and announcing myself as Chrome on Linux, I changed to MS Edge on Win10 and it works fine.
The javascript files Teams serves you change depending upon the platform and UA you provide. The issue is not completely solved but my calls no longer drop every 2 - 5 minutes.. now I can have a call going on for quite some time.. It does sometimes drop after like 40 minutes or so but that too is rare.
Maybe just being plain Chrome over FreeBSD and not spoof the User-Agent would help solve the issue completely.
 
Good to know quakerdoomer. I can add that I run the standard user-agent string. Since I only run Teams in Chrome and it "works", I haven't bothered changing things. I do mess around with the user agent string in Firefox, but normally, I just change the OS string to "FreeBSD not Linux" and things mostly work there.

I will also add that I created a virtual OSS device for the microphone and speaker combo, and it seemed to clear up the audio issues (at least people didn't complain like when I used pulse the last time). So, I might have a solution there as well, but I'll have to test more.
 
twschulz said:
Good to know quakerdoomer. I can add that I run the standard user-agent string. Since I only run Teams in Chrome and it "works", I haven't bothered changing things. I do mess around with the user agent string in Firefox, but normally, I just change the OS string to "FreeBSD not Linux" and things mostly work there.

I will also add that I created a virtual OSS device for the microphone and speaker combo, and it seemed to clear up the audio issues (at least people didn't complain like when I used pulse the last time). So, I might have a solution there as well, but I'll have to test more.
Click to expand...
Even I am using virtualoss but in my case I have no option since my internal microphone is unrecognized, so I am using an external one.
I am going to go back to ungoogled-chromium (which I had dropped suspecting that to have some audio incompatibility) and test if that too works fine now. Happy Holidays!
 
Good day everyone.
I use MS Teams in Chromium and I can hear, use the webcam, share my screen....
But here the microphone works very badly, noises and glitches. (Same Laptop, same Microfono in MS Windows works fine).
hselasky@ said:
There appears to be some kind of bug in the OSS backend for Chrome. Firefox OSS audio is much better, but Microsoft doesn't support that! I've found out that building Chrome with ALSA audio backend is more stable on FreeBSD and maybe we should consider that, because putting patches upstream chrome is very difficult!
Click to expand...

Do you think that rebuilding the port with ALSA support can improve the situation with the microphon?

Best regards,
 
Adding some history for the interested readers:

Video and audio works great in Chromium after you rebuild using the ALSA audio backend. And I sent some e-mails around to make this the default, speaking about the FreeBSD ports build of chrome. After fixing various issues in the cubeb audio backend for Firefox, I learnt that it's not so easy to integrate audio with web applications. Various audio parameters are specified directly in JavaScript, and forwarded to the audio backend. What caused "jitter" in Firefox, is probably the same that cause "jitter" in Chrome. It's like there is some undocumented consensus about how things are supposed to work. Especially the audio buffer size in samples is confusing. Web applications using audio may ask for a 4 second audio buffer, but expects to be queried every xx milliseconds for audio data via a JavaScript callback function. This is written nowhere, but probably is the way things work on Windows and MacOS, and vendors have adapted this bad habbit of asking for huge audio buffers, when small audio buffers are actually required. The big audio buffer has no purpose then, except for video playback. For realtime audio, which is part of Teams, this leads to endless "jitter". Previous when the OSS cubeb backend got asked to setup a 2x2 second audio buffer, it did so, and called Firefox process function every 2 seconds to refill audio data. Is 4 seconds of buffering "just in case", and then only use 16 ms worth of buffering during normal operation. Unless the backend developers get this right, yeah, you get jitterish audio. Because of the state of Chrome and FreeBSD and how the code is actually maintained, I'm not sure if fixing the OSS backend in Chrome is the way to go, when ALSA is already there. I rather spent some time last year to fix the ALSA OSS plugin, which now works just as good as native OSS. The way ALSA works and thinks about audio buffers is quite different from OSS again. In ALSA all audio buffering is done using so-called ring-buffers. The ring-buffers are in software of-course, but what happens when filling data too late leads to undefined behaviour simply. So the ALSA OSS audio plugin would work just fine, until the first buffer underrun, and then the statemachine of the ALSA OSS audio plugin would go into a permanent bad state. Now that's fixed, and ALSA OSS is good again, in my opinion. ALSA is yet another layer on top of things, but it's pretty OK from my point of view after going through the details down there.
 
This gives me hope... I was unable to compile firefox on my laptop (Lenovo Ideapad 720s-13ARR with a Ryzen 5 2500U) with 8 GB RAM, so I had to resort to pkg to install first www/firefox, then www/chromium. The Ryzen is fine, but there's not enough RAM to accommodate the compilation process.

Oh, and if someone can point me to a good way to mess with the user agent string in chromium on FreeBSD, that would be appreciated. Quick searches keep pointing me to Google's official docs and various Bugzillas, and it's a morass to dig through them. 😩
 
I spent 24 hours rebuilding www/chromium.
it took me back 13 years ago when I rebuilt Xorg or KDE :)....
But the problem with the microphone has not changed.
The microphone works very badly in Chromium.
And then I tried the online test in Firefox (I should have done it before) and the microphone works just as bad in www/firefox.
It seems to be a problem with my sound card settings.
But I'm sure that in previous versions of FreeBSD everything worked fine for me.
 
serjsk8 said:
I spent 24 hours rebuilding www/chromium.
it took me back 13 years ago when I rebuilt Xorg or KDE :)....
But the problem with the microphone has not changed.
The microphone works very badly in Chromium.
And then I tried the online test in Firefox (I should have done it before) and the microphone works just as bad in www/firefox.
It seems to be a problem with my sound card settings.
But I'm sure that in previous versions of FreeBSD everything worked fine for me.
Click to expand...

What hardware do you have again?
 
you mean my sound card?

cat /dev/sndstat
Installed devices:
pcm0: <Realtek ALC269 (Analog 2.0+HP/2.0)> (play/rec) default
pcm1: <Realtek ALC269 (Internal Analog Mic)> (rec)
 
It seems that I managed to achieve normal microphone quality in Chromium.
I had to set up the microphone via device.hints.
I checked the operation of the microphone on https://mic-test.com and the sound quality is now much better than it was before.
Tomorrow I'll check how MS Teams work.
But still, the microphone works strangely, when I speak into the microphone, I hear myself in the headphones.
 
Two points of interest from Microsoft:
  1. End of availability for classic Teams client - Microsoft Teams | Microsoft Learn
  2. Limits and specifications for Microsoft Teams - Microsoft Teams | Microsoft Learn – Browsers
Tuesday 2nd April (after the long weekend) was my first opportunity to test the new Teams in browsers on FreeBSD 15.0-CURRENT – primarily Firefox, secondarily Chromium. Tests were unexpectedly complicated, I'll not attempt to detail the results, but essentially:
  • things became much simpler after I enabled PulseAudio
– and to my great surprise, it was possible to sleep the system after using a USB audio device.

I chose to disable PulseAudio after three kernel panics, then someone dropped a hint that my first tests of the new Teams had loosely coincided with changes to the main branch of FreeBSD (for CURRENT). Two commits were reverted.

Now, with regard to <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727>:

christos said:
Please feel free to test the following patch, which fixes this bug:
<https://cgit.freebsd.org/src/commit/?id=44e128fe9d92c1a544b801cb56e907a66ef34691>
Click to expand...

christos big thanks!

I'll retest with PulseAudio enabled as soon as the commit reaches CURRENT through pkgbase.

Then, if things will be as they were early last week, I expect Firefox (with a particular user agent override for teams.microsoft.com and one other domain) to be good for essentials, but not for screen sharing.

I'll share hints and results in due course.
 
An experience.

The Firefox or Chromium (I don’t remember) had a microfone setting (and probably video setting too) set as on even if the application (Teams, Google meet or similar) showed it as offline.

I do not know if this has changed but the OS is not a really private one.

best, e
 
You must log in or register to reply here.
Back
Top