Closed Bug 1560632 Opened 6 years ago Closed 3 years ago

Tab with Google Hangouts Chat keeps coreaudiod busy (MacOS).

Categories

(Core :: Audio/Video: Playback, defect, P5)

Product:
Core
Component:
Audio/Video: Playback
Version:
69 Branch
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: yungchin, Assigned: padenot)

Details

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

Steps to reproduce:

Login at https://chat.google.com/ and leave the tab open for a while.

Actual results:

As long as this web app is running, coreaudiod (this is on MacOS 10.14.5) hovers at around 9-10% CPU usage, even though there's no chat activity and certainly no sound events. It drops to 0.00% as soon as I close the tab.

Expected results:

Keeping the same Hangouts Chat room open in Chrome, coreaudiod remains at 0.00% CPU usage. This is what you'd expect given that the app does not appear to be accessing audio resources.

Hi,

I wasn't able to reproduce this issue on Firefox 67.0.4 or Firefox Nightly 69.0a1 using MacOS X 10.14.5

Please test if the issue occurs to you in Safe mode. Here is a link that can help you with that:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

If the issue still occurs, please test it with a new profile, you can find the steps to do that below:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Thank you for reporting!

Flags: needinfo?(yungchin)

Thank you very much for helping to triage this.

I tried it in Safe Mode and the issue is still there, but Safe Mode seems a bit murky on my machine because it shows Firefox Multi-Account Containers as disabled, yet still opens tabs in containers.

I then followed your directions to create a new profile and that really runs without a trace of Multi-Account Containers. Even in this clean profile I definitely still see the issue.

I've now also installed Nightly (which also uses a clean profile), and there, I don't see the issue!

I guess that last bit is good news. But I'm not sure how to fix my stable installation. The fact that there the clean profile does not fix things seems to indicate it's not add-ons/settings related. But the fact that you don't see the issue on the same Firefox+MacOS version suggests it's still something to do with my setup?

Flags: needinfo?(yungchin)

PS: this is not really the place for it, but can I just say what an excellent new feature the profiles management is (new in 67.0 IIUC). This is what kept me from using Nightly more before (worry about clobbering my work profile). Very useful in debugging this issue!

I never figured out what caused this, but the behaviour is no longer present now that my stable install is at 68.0.1, therefore I'll close this issue. Thanks!

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID

I'd like to reopen this, as my previous comment turned out premature. The behaviour resurfaced while I was still on 68.0.1 (I'm not sure if it was really ever gone now), and it is still present now at 69.0.

What I don't understand: I'm quite sure my Nightly install didn't have the same problem at 69.0 so I will go through all the steps again as I did previously per Peter_M's suggestion. Marking this as "needs info" from me for the time being.

Status: RESOLVED → UNCONFIRMED
Flags: needinfo?(yungchin)
Resolution: INVALID → ---
Version: 67 Branch → 69 Branch

The issue does not occur on my end but I will add a component in order to involve the development-team in reviewing it.
Thank you for your input!

Component: Untriaged → WebRTC
Product: Firefox → Core

I am seeing this in a gmail tab with the new hangouts chat widget.
When I have this tab, coreaudiod uses up to 10% CPU.

Mac OS 10.14.6
Firefox 72.0b11

I'm seeing this problem, too, on two different computers. In my case CPU utilisation is lower, usually around 3%. It stops the moment I close the tab with Google chat, and it resumes the moment I open Google chat.

Mojave 10.14.6 and Firefox 72.0.2
Catalina 10.15.2 and also Firefox 72.0.2

I can't repro this on 74-76 on Catalina. Is this still happening for you on release?

Flags: needinfo?(erik)

Yes. Still a problem with Firefox on both, latest versions of Mojave and Catalina.

Here's output from a machine that I rebooted this morning, running Firefox with a Google Chat tab open most of the day:

➜  ~ uptime    
22:33  up 13:44, 2 users, load averages: 0.90 0.97 0.94
➜  ~ ps -vp 163
  PID STAT      TIME  SL  RE PAGEIN      VSZ    RSS   LIM     TSIZ  %CPU %MEM COMMAND
  163 Ss    23:24.92   0   0      0  4359664  16936     -        0   2.4  0.1 /usr/sbin/coreaudiod
➜  ~

On Catalina I'm seeing even higher CPU load, but maybe that's because it's a different type of computer. And, yes, CPU usage of coreaudiod drops immediately when I close the tab with Google Chat.

Let me know whether I can help diagnose this. I'm a software developer myself.

Flags: needinfo?(erik)

Does this happen with a new profile?

Flags: needinfo?(erik)

Yes, just tried. Same problem with a new profile. This does not happen in Safari by the way.

Flags: needinfo?(erik)

Strange. Let me make sure I understand how you're reproducing this:

  1. Open gmail.
  2. Select "Hangouts contacts" in the pane in the lower left-hand corner.
  3. Select a contact so that a chat window with that contact opens.

Also, I suppose I should ask whether there are any audio devices (speakers or mics) connected, be it through USB, Bluetooth, aux jack, etc.

Flags: needinfo?(erik)

No need to select a contact. It uses up CPU just existing.
On my Macbook Pro, with nothing attached, it still uses CPU.

However, the key here is that this is not "Hangouts contacts". This is the new Google Meet widget that may not be on standard gmail yet but is on enterprise orgs.

On standard gmail, it is an iframe that goes to https://hangouts.google.com
On this gmail (the offending one), it is an iframe that goes to https://chat.google.com

The simplest way to reproduce this is to open Firefox, even with a new profile, and paste the URL of a Google chat room. The moment that's fully loaded CPU usage goes up. Like Greg, I'm observing this on G Suite, the enterprise offering, and the URLs I'm talking about are on https://chat.google.com. If it helps I can send you a link to a video but that wouldn't really show more that what I've described.

The machine with Catalina is a 2017 15" MacBook Pro with no additional hardware attached. Also, on the Catalina machine Firefox does not have access to the microphone (set in the Security & Preference section of System Preferences) while on the Mojave machine it does. So, access to the microphone doesn't seem to have an impact either.

Flags: needinfo?(erik)

Ok, let me see if I can get access to g-suite somehow...

I've had no luck registering for a trial gsuite account; they think I'm going to use it for spam.

I do have access to meet.google.com though. When using meet.google.com, I don't see any activity in coreaudio before the gUM prompt, in either Firefox or Chrome. I see coreaudio at about 4% with Chrome during the gUM permission prompt, before granting. In Firefox, that number is more like 7%, so a bit higher.

Maybe this is due to differences in how chat.google.com handles gUM? Or maybe there's some other resource we're acquiring?

This looks promising. I can observe the following:

  1. When I'm logged in with my G Suite account and go to meet.google.com, I'm offered to start a meeting. While on that page coreaudiod is a 0%.
  2. When I click to start a meeting Firefox asks me to allow access to mike and camera. During this time coreaudiod is at ~2%.
  3. If I don't grant access coreaudiod stays at ~2%. If I do allow access, coreaudiod goes to ~1% CPU usage.
  4. The effect seems to "stack" with chat in another tab, i.e. with chat and meet open CPU usage hovers around 4%.

Denying gUM also causes coreaudio to waste cycles when using other webrtc services, like whereby. This happens with both Firefox and Chrome, however.

Any idea what might be going on here? Why is denying gUM having this effect?

Flags: needinfo?(jib)

What is interesting is that Google Chat (the one in G Suite) never asks for permission to access the microphone. It triggers the behaviour in coreaudiod without any request. So, it might be that it's not the act of denying access that causes it, but the inability to use a resource. It's curious how the code in Chat can get to that point without triggering the request to access anything.

It might not be gUM then. It is really hard to tell since I can't use g-suite.

Priority: -- → P5

I also don't have g-suite, sorry.

Flags: needinfo?(jib)

I can confirm this behaviour. FF 75.0, exclusive to chat.google.com in a gsuite account. As soon as tab closes, coreaudiod drops to 0%.

This may be helpful: When opening FF, coreaudiod still jumps to 9-10% even if the chat tab has yet to be visited. In other words, close FF with "restore previous session" and make sure the active tab is not chat. Re-open FF and coreaudiod usage climbs, even though the chat tab hasn't been loaded (or perhaps it's been loaded, and just not rendered?).

I have experienced the same issue on Outlook and Discord. I need to mute the tabs to silence coreaudiod. Outlook doesn’t have access to camera or mic. Perhaps related to notification sounds?

@Kohei This is odd. I cannot reproduce this issue in Discord. When I log into Discord and enter a channel, coreaudiod stays at 0% for me. Also, when I mute the tab with Google Chat, coreaudiod keeps using CPU cycles. Switching to another tab also doesn't stop the issue for me, coreaudiod keeps using CPU cycles.

Can you maybe describe in detail which steps you took in Discord and Outlook? And can you clarify what you mean by "silencing" coreaudiod? Do you literally mean no sound, or do you mean, figuratively, no CPU usage?

Flags: needinfo?(kohei.yoshino)

I am experiencing this issue with Outlook in Firefox 76.0.1 on Mac OSX Mojave.

Here are steps to reproduce.

  1. Log in to https://outlook.office.com and go to the Mail tab (i.e. the inbox)
  2. Wait for a notification for a calendar event to pop up on that tab.
    Result: Sound plays and coreaudiod CPU usage spikes (~12% on my machine) and stays there until the tab is closed.
    Expected: Sound to play without hogging resources indefinitely

Note:

  • You can trigger a calendar notification by making a meeting in next 15-30 minutes and setting the notification to be 1 hour beforehand.

I have the same issue as described by @mvbooeke. The same steps are sufficient to reproduce the issue.

I can work around the issue by reloading the page.

I'd like to note that the issue is not related to system notifications from the website, but only to when the website plays the sound.

I had the issue with macOS 10.15.4, and it's still reproducible with macOS 10.15.5.

Just confirming that I've updated to Firefox 77.0.1 and MacOS Catalina 10.15.5 and I'm still seeing the issue.

coreaudioD process takes a huge amount of CPU when Outlook.com plays a notification sound and doesn't let it go until your reload the tab or the browser.

Muting the tab doesn't help with this issue, because the tab still plays the first part of the Outlook notification sound before muting.

I don't know if that's another unrelated bug or if it is another facet of the coreaudiod issue.

In Outlook, go to Settings > General > Notifications, uncheck “Play a sound when a message arrives” and “Play a sound when I receive a reminder” then the coreaudiod CPU becomes 0%. I don’t have to mute the tab any more. Not sure about Discord; I haven’t used it for a while.

Flags: needinfo?(kohei.yoshino)

I am also seeing this in Outlook on the Web, using Firefox 81.0.1.

-When first logging in, everything is fine.
-When Outlook makes its first sound, coreaudiod jumps to around 9% and stays there. This behavior has been reported in other software when using the microphone, but microphone permission is turned off.
-Refreshing the Outlook tab will make coreaudiod return to 0%, where it will stay until another Outlook sound is made. Then the process repeats.

I want to keep Firefox as my primary browser, but this issue is a real drain, both literally (on my battery life) and figuratively.

firefox 93.0 still has this issue. the coreaudiod process keeps consuming 9%+ CPU when outlook website is open for some while. safari/chrome/chromium don't have this issue.

This does not sound like a webrtc bug to me, if we're just talking about webmail making notification sounds.

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

This is known: those websites are using an AudioContext, and they are not suspending it, so a real-time thread still renders audio (in this case, silence).

This will be fixed in bug 1735412, I'm set to work on this quarter. https://bugzilla.mozilla.org/show_bug.cgi?id=1735412#c2 has background informations about this.

Flags: needinfo?(padenot)

I'm taking this bug to check back that this really is fixed when I'm done with the other bug.

Assignee: nobody → padenot
Status: UNCONFIRMED → NEW
Ever confirmed: true

Recent comments on this ticket are about Outlook, obviously, even though this started as a report about a problem with Google Chat.

FWIW, it looks like Google fixed the problem with Chat on their side. At least I can't reproduce the problem with Chat anymore.

(Firefox 93, macOS 11.6)

Severity: normal → S3

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Closing the bug as incomplete.

For more information, please visit auto_nag documentation.

Status: NEW → RESOLVED
Closed: 6 years ago → 3 years ago
Flags: needinfo?(yungchin)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.