1747121 - [Meet] Utilizing external USB Audio interfaces introduces distracting audio artifacts on input

Status: RESOLVED DUPLICATE of bug 1739505

(Core :: WebRTC: Audio/Video, defect)

Description

[Mark Richards [:freshness]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:95.0) Gecko/20100101 Firefox/95.0

External devices tested with:
The Focusrite ClaClarett 2Pre USB - 48 kHz sample rate.
Focusrite Scarlett - 48 kHz sample rate.
The Focusrite ClaClarett 2Pre USB - 44.1 kHz sample rate
Focusrite Scarlett - 44.1 kHz sample rate

STR:
1. Go to New Meeting (Google Meet)
2. Wait for the meeting to open in a new tab
3. Give microphone permission

Expected behavior: The microphone interface should work as expected

Actual behavior: Distorted microphone input is heard by the far end anytime the local participant speaks. Setting different sample rates or bit depths does not remediate the issue.

Works fine in Google Chrome

Comment 1

[Michael Froman [:mjf]]

:padenot (knowing full well that you are on PTO so not expecting an answer until you return), any thoughts here?

Comment 2

[Michael Froman [:mjf]]

For reference, I successfully tested at 48k using my MOTU 828mk3 on both google meet and whereby.com with v95 and v97. This is a firewire device, so that could be one factor, but it doesn't seem like we're having issues with all external devices.

Comment 3

[Paul Adenot (:padenot)]

Yeah I'm using an old Focusrite Scarlett 6i6 myself, and it works well, lots of other people have similar setups with other brand / models.

Mark, would you mind giving us the raw data from about:support so we can know a bit more about your setup and get this fixed? Please do so with the sound cards attached to the machine, so we can have the exact models, thanks !

Comment 4

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Is there any indication that this is a WebRTC issue, as opposed to an audio capture issue? Should this be moved to a different component?

Comment 5

[Andy Kochendorfer]

USB audio interface testing for sample rate errors: Focusrite Claret 2Pre USB tested at 44.1, 48, 88.2, 96, 176.4, and 192 kHz sample rates. Please see https://drive.google.com/file/d/1gBDxpkYjaVuFKKs_C-dsi5zPWAIWL3tY/view?usp=sharing. 44.1 and 48 kHz seem to function as intended, but the higher sample rates, although audible, have lip sync issues.

Previously (Oct. 2021 testing), 48 kHz rate audio from the Focusrite Claret 2Pre USB did not function.

Comment 6

[Paul Adenot (:padenot)]

I don't think we support changing the sample-rate dynamically like that, but we might be able to. There are a few glitches at those points in time, not sure why. I don't think AV sync is particularly good at any point at the video (including the very beginning), but I'm not too sure how the video has been recorded, happy to have some details on that.

We've indeed fixed something not too long ago in the mentioned timeframe that could be the cause of this particular card working.

I haven't been able to discern any audio of the input glitches outside of those sample-rate changes on the Claret 2Pre in the video above, am I missing something?

All that said, if AV has specific needs/questions, we can also chat directly, I'd be happy to help, I'm @padenot on slack and everywhere else.

Comment 7

[Andy Kochendorfer]

@padenot: I was recording in Google Meet using the background blur function (it would not turn off), which in my testings seems to lower the video frame to 20 FPS or fewer, so that may account for some poor lip sync at the lower frame rates. Background blur is an extremely popular Zoom function among Mozillians. FYI - Video input device for the test was a Elgato HD60 S+, which provides me 1080P 30 FPS daily on Zoom.

Comment 8

[Paul Adenot (:padenot)]

The background blur issue is known and fixed (afaik) in Firefox Nightly (currently 97).

Comment 9

[Mark Richards [:freshness]]

Hello Khanh,

I know that you have a Focusrite Scarlett Solo, and experiencing this issue. Would you mind giving us the raw data from about:support when experiencing this issue with Google Meet?

Comment 10

[Mark Richards [:freshness]]

Attachment: FocusriteScarlettSolo.rtf

Added about:support raw data for [e-mail] (primary user)

Comment 11

[Paul Adenot (:padenot)]

Is this setup using the Scarlett Solo directly, or one of the numerous virtual audio devices that are present on this machine?

Can I ask for this issue to be characterized? The video Mark recorded shows that there are no glitches on a Focusrite Claret 2Pre, but glitches are reported in the initial comment on both a Claret 2Pre and a Scarlet (not sure of the model), and now knguyen@ reports glitches on a Scarlett Solo?

The default audio device on this machine are set up in a way where two sound different sound cards are in use: the built-in jack of the laptop for output (maybe with regular headphones), and the Scarlett Solo is being used for audio input. This is not a setup that will generally work well because of clock drifts, and the headphones should be connected to the Scarlett, maybe via a 3.5mm -> 6.35mm adapter.

It "works" in Chrome because they take a hit in audio latency and reclock themselves.

Comment 12

[Mark Richards [:freshness]]

Attachment: raw-data-google-meet-012022-Claret2PreUSB-interface.rtf

We were able to reproduce this bug using the Claret 2 Pre USB today, and Padenot's latest comment seems to be the discrepancy here. When using a sample rate at or above 96kHz and utilizing separate sound cards for input and output, the far-end hears audio artifacts comparable to clock-drift. about:support dump from the Test-PC used to introduce this issue has been attached to this bug.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0

STR:

1. Set the System Audio input device to Claret 2 Pre (Or any external USB audio interface)
2. Ensure sample rate is 96kHz or above (Artifacts are less audible with lower sample rates)
3. Set System Audio output device to laptop speakers or headphones plugged directly into the 3.5mm jack
4. Join Google Meet, set IO accordingly
5. Join the same meeting from a different computer entirely, and listen to the audio quality from your test system

Additional notes:
While conducting this test, we were able to experience the clock-drift issue when utilizing the Claret 2 for both Input AND Output, but only after changing sample rates multiple times and a long testing session, so a myriad of root causes could be the culprit there.