User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Using Firefox with BigBlueButton standard installation on our root server in combination with Bluetooth headsets (PLT Voyager/Aukey EP-T10) results in crackling sound. This also occurs on the demo-server (demo.bigbluebutton.org).

This is not happening if chromium based browsers are used.

I can prvide logs if needed.

Actual results:

Crackling sound.

Also the devices are not correctly displayed when using Firefox with bigbluebutton.

Shows input-0 and input-1 instead of the device name.

The crackling sound is hard to ignore and makes it hard to understand people. This is not present with the build in microphones.

Expected results:

Clear sound without cracks.

Devices shown with their appropriate device names, which is the case for Chromium based browsers.

Oh btw. This also is the case for the latest nightly 82.0a1 from today.

[Tracking Requested - why for this release]:

1663917 has lots of fixes, that will probably fix this, but it's proving hard to land without crashes.

Thanks for confiming. I already got nuts about this issue. Spend hours to try to find a work around. Check all policies for our GPOs regarding Firefox. Reinstalling the server several times, etc . Hopefully you get it working soon without crashes. If you need anything send me a mail.

Thanks for the fix. It works much better now. (Build-ID: 20200923212316) Also the echo test of BBB is now done in less than a second! Good job! This was a big flaw with FF in combination with BBB as well for our users. Only thing still not working is the device names in the settings of BBB. (see screenshot).

Screenshot:
https://ibb.co/7GDrCtL

Also it seems I managed once to get the crackling sound back, but could not reproduce it yet.

Christian, thanks for the followup. This largely fix the biggest problems, but I plan to continue making this better.

I'd like to reproduce the device names issue, but I've logged in the demo bbb instance, and I have a 404 when trying to join a call, is this known?

demo.bigbluebutton.org seems to be not working right now. I also get 404 trying to start a room. But the test.bigbluebutton.org is working fine and shows the issue as well.

Oh one more question. Will this land any time soon in ESR-version of FF or is it too experimental? I only see that it is targeted for 83 branch. Thx for the information in advance!

(In reply to Christian Finke from comment #8)

Oh one more question. Will this land any time soon in ESR-version of FF or is it too experimental? I only see that it is targeted for 83 branch. Thx for the information in advance!

I'd like this to bake a little bit more on release builds (this is set for inclusion in release 83, currently in Nightly as you saw), and then we'll see.

In the meantime, I'll use the links you gave me to fix see what this naming thing is about.

So, I had a look, and it works well here, but I don't exactly have the same device. I see the correct name for input and output devices. Does your app request for permission before displaying the list of devices?

It is expected for the names to not be available before a user action giving explicit consent to enumerate their local devices, because this has very strong privacy implications.

Hi Paul, sorry for the late responds. Vacations and so on. The Problem occurs when the user does not save the permissions, So it is really only a problem with permissions given by the user. I don't know how you want to handle this privacy-wise. But it is not really user friendly if you ask me, since you don't know which audio input/output you selected in BBB because FF was not given the permission to hand over the device name. For me it is only a device name. Sure you can gather this information and guess what device the user is using or even so use a security flaw in a driver of the given device. But this are very unlikely scenarios, if you ask me. So for user friendlyness I would prefer a permission allowance that, (after first confirmation and with that the initial "I do trust this site") at least passes through the device names or that sets the permissions on a timer or for that unique visit of the website to set up your WebRTC-Devices with ease and without guessing which device I have to take to get my microphone XY or speakers XZ working on a software like BBB. But yes this flaw seems more like a privacy versus user friendliness discussion and it is actually working if you save the permissions you have given, but you will have to repeat loading the page and give permission to each device once at a time.

Thank you for looking into this issue. Since our company guidelines deny saving permissions on websites like those for the microphone I did not really notice that it is a permission issue.

This is unlikely to change, in its current form, for the obvious reasons that you pointed out.

Jan-Ivar, there are recent development in this area, would you mind offering a few pointers? I seem to recall a move towards a browser-controlled device selection prompt?

The spec has actually gotten even stricter in response to privacy review: labels are no longer tied to permission but to active capture.

So expect labels to go away completely ahead of getUserMedia success, as of bug 1528042.

The rationale is they're an unnecessary privacy risk, even behind permission. The spec-supported model most sites follow is:

1. Open the same camera/mic from last session using deviceId (system defaults on initial visit)
2. Add an ⚙️ options panel where users can change their camera/mic preference during live capture.

My recommendation is to follow that pattern, as anything else is likely to break soon even in Chrome, and already in Safari.

If that doesn't suit your app, your only option would be to cache the labels yourself. This should work well enough except the occasional time a user inserts a brand new device.

I seem to recall a move towards a browser-controlled device selection prompt?

Yes, long term we hope to deprecate in-content device pickers in favor of in-browser ones as seen in Firefox & other APIs like getDisplayMedia.

Closing this because it's working as intended, even if it's not what is expected.

I just tested it with the latest FF Nightly 84a1 (2020-11-11)(64-bit). At first the Bluetooth Mic worked fine but then due to the increasing count of webcams in BBB (around 16) my CPU load spiked up to 100% after that my Mic sound had the same crackling sound as mentioned before. So this is not a fully robust solution to the issue. Should be also reproduceable with synthetic load but did not test that yet.

It's best to open a different ticket for a different issue, but never mind.

Can you please tell us what computer you're testing on, its OS, whether it's the same bluetooth headset, etc. More fixes should arrive in the next few days, specifically for bluetooth. Raw data from about:support has lots of useful info.

Also if we can have access to your synthetic load page it would be nice.

Same Headset same issue but only when there was a high latency spike like 100% CPU load on my ThinkPad T460p. The crackling sound did not recover, after the load was lower again (room with less webcams and no background processes).

Sorry for reusing the issue, will have this in mind for the next time.

(In reply to Paul Adenot (:padenot) from comment #16)

Also if we can have access to your synthetic load page it would be nice.

What do you mean with synthetic load page? I want to test it with something like prime95 and have a look if I can reproduce it in the case of that synthetic load in the background.

Interesting. I'll try to repro on my end with my Sony WHX1000-m3 on a Windows 10 laptop. I find that bluetooth on Windows is quick prone to under-running, so I'm increasing latencies at the moment, to try to mitigate this (not finished).

For the synthetic load page, I thought you were talking about a page with 15 "fake" peers to test performance, not external load with a program.

For external load, prime95 works (I've been using this on Windows), We've also been using stress-ng on mac and linux.

I've bumped the latency up when using bluetooth devices in handsfree (which should be the case), maybe it's worth another try in Firefox Nightly.

Hey Christian,
Can you still reproduce this issue or should we close it?

Hi,

I got this issue with the "newest" firefox 91.0 (64bit) since today morning. After update my bluethooth microphone (TaoTronics TT-BH16 bluetooth headphones) does a crackling sound in BigBlueButton (can be tested in echotest) and Jitsi with Firefox. Everything works fine in Chrome or with the internal notebook microphone.

A narrowed down with mozregression:
Last good revision: 3793e0a6acf5b43cc37cf8164047975bf08b0852
First bad revision: f0c736218ab6592dbd8f973af162fbac414266fd
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3793e0a6acf5b43cc37cf8164047975bf08b0852&tochange=f0c736218ab6592dbd8f973af162fbac414266fd

Hi,

I can confirm this problem. Microphone audio with Plantronics PLT 5200 headset worked perfectly well until I updated Firefox to version 91. After the update, the quality was so bad that no one understood a word I said. Only the audio input (mic) was affected. Audio output was always OK.

I am using Fedora 34, Jitsi and 3CX.

After a downgrade to Firefox 87, the audio quality was fine again.

All, we're fixing this in bug 1725810, that already has patches for this issue.