Open Bug 1978259 Opened 1 year ago Updated 5 months ago

Audio channels shift in Teams

Categories

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

Product:
Core
Component:
WebRTC: Audio/Video
Version:
Firefox 141
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: forelf1, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(1 file)

about:support output
81.67 KB, text/plain
Details

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

Steps to reproduce:

  1. Start or join a call. (Group calls had the same problem)
  2. Wait ~1 minute.
  3. Audio shifts from center stereo to primarily right channel.

Actual results:

Audio in calls shift to mostly right channel (left channel is still active, but much less prominent).
Didn't notice other messengers to be affected (for example Google Meet).
Just in case checked it on another PC and it had the same issue.

Expected results:

Nothing - audio should have remained centered.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Thanks for reporting! To help diagnose this issue better, please can you:

  1. Type "about:support" in Firefox and copy-paste its contents here
  2. Does this reproduce in a clean profile or Troubleshoot Mode?
  3. Capture a log when the issue occurs:
  • In Firefox, ideally freshly started with no other tabs, go to about:logging in a new tab
  • Select the Media preset
  • Enable "stack traces for log messages"
  • Click on "Set Log Modules"
  • Click Start Logging
  • Reproduce the bug
  • Back on about:logging, click Stop Logging
  • In the new tab that appears with the Firefox Profiler web application, in the top right click the button to upload the profile
  • Make sure hidden threads are included and upload, then share the link here or send privately to a Mozilla developer
    -See https://paul.cx/public/about-logging-presentation.webm for a video walk-through
  1. If this used to work in an earlier version of Firefox, please do a bisection to find the exact change that caused this (https://mozilla.github.io/mozregression/)
Flags: needinfo?(forelf1)
Attached file about:support output —

I reproduced this in a fresh profile, but the profiler.firefox.com says the upload is too big (8 min recording). Is there any way to get a local one and upload it somewhere else?

Flags: needinfo?(forelf1)

I had to cut only the last minute: https://share.firefox.dev/46iiFA1

Regarding the versions - I can't say for sure, as I guess it started around when Skype moved to Teams, so around May 2025.

Karl, is this something you could take a look? I saw a lot of MTG usage in the profile, and wonder if this should be related with MTG/WebAudio, or a cubeb problem. Thanks!

Flags: needinfo?(karlt)

Thank you for all the details.
I assume you observed this behavior with the "Динамики (TOPPING USB DAC)" output device.
Does the same behavior occur with different output devices?

I can see from the profile that Web Audio is in use for an AnalyserNode, but not for StereoPannerNode, nor PannerNode, nor AudioWorkletNode.

A profile with the "WebRTC" preset would be more suited to this situation, as it would have more relevant logging turned on.
Try to record the profile while setting up the connection to the call until the problem is noticed.
Some things are recorded only at set-up.

Let's move this report to WebRTC:Audio/Video because that is where similar issues would be reported, and this will be seen by people who may have seen such reports.

Perhaps the issue is lower level in cubeb, but that might be less likely given this doesn't affect other WebRTC platforms.

Component: Audio/Video: Playback → WebRTC: Audio/Video
Flags: needinfo?(karlt)

I am sure that this is a duplicate bug that was reported before, though I am having trouble finding the first filing. There is precedent for intentional right panning https://bugzilla.mozilla.org/show_bug.cgi?id=1027713 .

(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #8)

I am sure that this is a duplicate bug that was reported before, though I am having trouble finding the first filing. There is precedent for intentional right panning https://bugzilla.mozilla.org/show_bug.cgi?id=1027713 .

Looks like it was https://bugzilla.mozilla.org/show_bug.cgi?id=1961702 , which contained no details.

Duplicate of this bug: 1961702
Blocks: teams

(In reply to Karl Tomlinson (:karlt) from comment #7)

Thank you for all the details.
I assume you observed this behavior with the "Динамики (TOPPING USB DAC)" output device.
Does the same behavior occur with different output devices?

I can see from the profile that Web Audio is in use for an AnalyserNode, but not for StereoPannerNode, nor PannerNode, nor AudioWorkletNode.

A profile with the "WebRTC" preset would be more suited to this situation, as it would have more relevant logging turned on.
Try to record the profile while setting up the connection to the call until the problem is noticed.
Some things are recorded only at set-up.

Let's move this report to WebRTC:Audio/Video because that is where similar issues would be reported, and this will be seen by people who may have seen such reports.

Perhaps the issue is lower level in cubeb, but that might be less likely given this doesn't affect other WebRTC platforms.

As this issue starts showing clearly (it slowly shifts) after about 6 minutes, I had to to two recordings. Used the WebRTC profile.
This is the beginning of a call: https://share.firefox.dev/4lRxSga
And this is the end of a different call: https://share.firefox.dev/4oajnWi

I do use TOPPING USB DAC (generic USB audio device) as output. And Rode VideoMic Go 2 as input (generic microphone too). However just to note again that I notice this issue only in Teams.

I also experience this in Zoom web and Google Meet on Windows. I'm using an Apple USB-C to 3.5mm Headphone Jack Adapter.

The severity field is not set for this bug.
:jib, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jib)

FWIW, this sounds to me more like the Haas Effect than panning, with the right channel playing just far enough before the left that there is a noticeable bias towards the right.

(In reply to James Teh [:Jamie] from comment #14)

FWIW, this sounds to me more like the Haas Effect than panning, with the right channel playing just far enough before the left that there is a noticeable bias towards the right.

Does Firefox even implement this? And if yes, then why?

As for my reported case, microphones used were mono and the effect becomes stronger over time. So it is either some audio fiddling from Teams, or something within Firefox.

(In reply to Andrew S. from comment #15)

Does Firefox even implement [the Haas Effect]? And if yes, then why?

To be clear, I'm not suggesting this is deliberate or something that is specifically implemented. I'm noting that this is what it sounds like, just in case that might give some hint as to what's going wrong. If audio in the left channel was delayed slightly due to some bug, that would cause this. I don't know why that would be, though; I'm not familiar with the audio or WebRTC code.

(In reply to James Teh [:Jamie] from comment #16)

(In reply to Andrew S. from comment #15)

Does Firefox even implement [the Haas Effect]? And if yes, then why?

To be clear, I'm not suggesting this is deliberate or something that is specifically implemented. I'm noting that this is what it sounds like, just in case that might give some hint as to what's going wrong. If audio in the left channel was delayed slightly due to some bug, that would cause this. I don't know why that would be, though; I'm not familiar with the audio or WebRTC code.

I just recorded the output via Audacity. And it seems like you are right - left and right channels just desync over time.
Here's a screenshot of the waveform: https://1drv.ms/i/c/2839e5b547e6bafd/Edx9QxBKswBPtvpzYaxbWE0BqV0e4O926IbcS_duvg1W7g?e=aJZs6s
At the same time if any other tab produced a sound (tried a random stereo check to produce a center sound) - it was aligned correctly.

Duplicate of this bug: 1976616

Bug 1976616 suggests that this started happening in Firefox 140.

(In reply to James Teh [:Jamie] from comment #19)

Bug 1976616 suggests that this started happening in Firefox 140.

Cant tell for sure, but it happened way before that for me.

I tried to track this down with mozregression using both Zoom and Google Meet, but of course now that I'm trying to reproduce it for testing purposes, I can't, even though it happened in a real meeting just this morning. 🤦‍♂️

This happened to me the first time on June 25th, and continues to occur 100% of the time when discord voice.

(In reply to James Teh [:Jamie] from comment #21)

I tried to track this down with mozregression using both Zoom and Google Meet, but of course now that I'm trying to reproduce it for testing purposes, I can't, even though it happened in a real meeting just this morning. 🤦‍♂️

Can't say anything about Zoom, but Google Meet works fine for me - weekly hour long meeting and didn't notice anything.

(In reply to Yuxiao Sun from comment #22)

This happened to me the first time on June 25th, and continues to occur 100% of the time when discord voice.

Hi Yuxiao, I see you provided evidence of drift in bug 1976616 which was duped to here. Since it repros reliably for you, would you be able to install and run the mozregression tool on it to narrow down a regression range? — That said, I realize this might not work if waiting an hour is required to observe the symptom. But I wanted to mention the tool in case you had a quicker way to verify drift.

Severity: -- → S3
Flags: needinfo?(jib) → needinfo?(yuxiaosunx)

While it doesn't actually take an entire hour to observe, it does take several minutes for the drift to be obvious enough to confirm. I'll try running that next time I'm on discord.

If it helps in the meantime, I used discord voice chat with no issues on June 22nd and observed the issue on June 25th.

Flags: needinfo?(yuxiaosunx)

I spent a while with mozregression and was somewhat surprised to see that I observe this behavior even at the 2025-06-11 build, which was the earliest I tested. Does firefox keep logs of updates and versions going back far enough for me to see what I was running on June 22nd?

It's one of the first buttons in about:support, or it's also towards the bottom of the General settings.

mozregression output at the end:

2025-10-18T01:02:45.666000: INFO : Narrowed integration regression window from [431cd644, 7d101890] (3 builds) to [431cd644, 7b783144] (2 builds) (~1 steps left)
2025-10-18T01:02:45.670000: DEBUG : Starting merge handling...
2025-10-18T01:02:45.671000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=7b7831449f3dfc83d451a60e73ba8f42de429be0&full=1
2025-10-18T01:02:45.671000: DEBUG : redo: attempt 1/3
2025-10-18T01:02:45.671000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=7b7831449f3dfc83d451a60e73ba8f42de429be0&full=1',), kwargs: {}, attempt #1
2025-10-18T01:02:45.672000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2025-10-18T01:02:45.751000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=7b7831449f3dfc83d451a60e73ba8f42de429be0&full=1 HTTP/1.1" 302 0
2025-10-18T01:02:45.752000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg-edge.mozilla.org
2025-10-18T01:02:46.512000: DEBUG : urllib3.connectionpool: https://hg-edge.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=7b7831449f3dfc83d451a60e73ba8f42de429be0&full=1 HTTP/1.1" 200 None
2025-10-18T01:02:46.514000: DEBUG : Found commit message:
Bug 1958963 Expose all speaker devices, irrespective of groupId, upon microphone access. r=karlt

Relaxes exposure criteria for speakers in the navigator.mediaDevices.enumerateDevices() API,
to match the recent spec change in w3c/mediacapture-output#150 and other implementations for
web compatibility.

The old behavior was to only expose speakers whose groupId is the same as that of any microphone,
once the document is using a microphone.

The new behavior is to expose all speakers once the document is using a microphone.

The old behavior is retained for RFPTarget::MediaDevices, to avoid any new exposure there.

Also fixes an assumption in WPT test
MediaDevices-enumerateDevices-per-origin-ids.sub.https.html broken by this patch
about the total number of devices exposed after gUM in an iframe vs the top frame.

Differential Revision: https://phabricator.services.mozilla.com/D246001

2025-10-18T01:02:46.515000: DEBUG : Did not find a branch, checking all integration branches
2025-10-18T01:02:46.515000: INFO : The bisection is done.
2025-10-18T01:02:46.516000: INFO : Stopped

Thank you!

Keywords: regression
Regressed by: 1958963

(In reply to James Teh [:Jamie] from comment #29)

Thank you!

Hello. I'm sorry to have to ask this here, but I'm on Firefox 145.0 (64-bit) and still have the problem. In which version of Firefox will we be able to have this regression of 1958963 ?

This bug exists since Firefox 140 for me, up to at least the current Firefox 147.0.1 on Windows.
Tested with Discord and Microsoft Teams.

Seems to only affect WebRTC and no other audio (MP4 video playback etc is fine).
WebRTC audio is synchronized in the beginning. Usually takes less than 30 seconds to hear the first shift to the right channel. More shifts keep happening over time.

Teams channel desync keeps is still present in 150 Beta.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: