Closed Bug 1555726 Opened 2 years ago Closed 2 years ago

Using Firefox on Windows 10 makes Conexant audio driver's Flow.exe program use excessive CPU

Categories

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

67 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1569712

People

(Reporter: stevenhrosenberg, Unassigned)

Details

(Whiteboard: [qf:p2:resource])

Attachments

(1 file)

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

Steps to reproduce:

Run the Firefox browser on a Windows 10 computer with Bang & Olufsen sound hardware using the Conexant audio driver (version 9.0.160.51, but all recent versions exhibit the same problem).

Actual results:

This only happens with Firefox. After browser is launched, a program supplied by the Conexant audio driver, Flow.exe begins running, and both Firefox and Flow.exe combined can take 50% to 60% of available CPU causing fans to run on high and reducing performance.

Expected results:

Firefox should use a normal amount of CPU, and Conexant's Flow.exe should not be using this much CPU.

Component: Untriaged → Performance
Product: Firefox → Core
Whiteboard: [qf]

Can you disable the Ghostery plugin and attempt to reproduce this? It looks like there is an audio-related function that Ghostery is using that may be causing this problem and it would be really helpful if you could try this step! Thank you!

kinitek: The function in question is nsPIDOMWindowInner::IsPlayingAudio and it is called both from the parent process and the content process by Ghostery. I assume that it is doing this to determine whether audio is playing and then block it.

Flags: needinfo?(stevenhrosenberg)

nsPIDOMWindowInner::IsPlayingAudio doesn't interact with the OS audio APIs directly, so I don't think that'd cause any problems related to this.

Reading through the HP forum thread, it sounds like this may be outside of our control. It's possible changing the way we interact with the OS audio APIs could help avoid this issue, but I don't know what Flow.exe is trying to do so it's hard to guess if a workaround is possible within Firefox without being able to reproduce/investigate this locally - I don't have access to any of the affected configurations.

For anyone who can reproduce this: it might be worth setting the pref "media.cubeb.backend" to "winmm", restarting Firefox, and seeing if that changes the behaviour of Flow.exe in any way - I'd be surprised if it did, but I don't have any other immediate suggestions.

(In reply to Will Hawkins from comment #2)

Can you disable the Ghostery plugin and attempt to reproduce this? It looks like there is an audio-related function that Ghostery is using that may be causing this problem and it would be really helpful if you could try this step! Thank you!

kinitek: The function in question is nsPIDOMWindowInner::IsPlayingAudio and it is called both from the parent process and the content process by Ghostery. I assume that it is doing this to determine whether audio is playing and then block it.

Disabling Ghostery has no effect. Firefox and Flow.exe are both still using MUCH more CPU than they otherwise would.

Note: One workaround for this is to rename Flow.exe as something like _Flow.exe so the Conexant software doesn't call it at all. Audio doesn't appear to be affected. However, this is still an ugly hack that most new users won't discover before dumping Firefox. Without Flow.exe, Firefox uses much less CPU than Chrome in Windows.

Flags: needinfo?(stevenhrosenberg)

(In reply to Matthew Gregan [:kinetik] from comment #3)

nsPIDOMWindowInner::IsPlayingAudio doesn't interact with the OS audio APIs directly, so I don't think that'd cause any problems related to this.

Reading through the HP forum thread, it sounds like this may be outside of our control. It's possible changing the way we interact with the OS audio APIs could help avoid this issue, but I don't know what Flow.exe is trying to do so it's hard to guess if a workaround is possible within Firefox without being able to reproduce/investigate this locally - I don't have access to any of the affected configurations.

For anyone who can reproduce this: it might be worth setting the pref "media.cubeb.backend" to "winmm", restarting Firefox, and seeing if that changes the behaviour of Flow.exe in any way - I'd be surprised if it did, but I don't have any other immediate suggestions.

I don't see media.cubeb.backend in my about:config. All I have is media.cubeb.logging_level and media.cubeb.sandbox.

(In reply to Steven Rosenberg from comment #4)

(In reply to Will Hawkins from comment #2)

Can you disable the Ghostery plugin and attempt to reproduce this? It looks like there is an audio-related function that Ghostery is using that may be causing this problem and it would be really helpful if you could try this step! Thank you!

kinitek: The function in question is nsPIDOMWindowInner::IsPlayingAudio and it is called both from the parent process and the content process by Ghostery. I assume that it is doing this to determine whether audio is playing and then block it.

Disabling Ghostery has no effect. Firefox and Flow.exe are both still using MUCH more CPU than they otherwise would.

Note: One workaround for this is to rename Flow.exe as something like _Flow.exe so the Conexant software doesn't call it at all. Audio doesn't appear to be affected. However, this is still an ugly hack that most new users won't discover before dumping Firefox. Without Flow.exe, Firefox uses much less CPU than Chrome in Windows.

I also disabled all extensions, and that had no effect on this issue.

Just so you can see the extent and parameters of the problem, here are some images.

When Flow.exe is disabled (by renaming it _Flow.exe so the Conexant audio system cannot find it), this "nag" screen appears with every reboot. It is annoying but tolerable for experienced users (but would definitely put off new users):

http://stevenrosenberg.net/documents/images/browsers/firefox/2019_0627_flow_exe_conexant_popup.jpg

Here is what the CPU usage looks like when Flow.exe is active (CPU usage is unusually high):

http://stevenrosenberg.net/documents/images/browsers/firefox/2019_0627_firefox_with_flow_exe.jpg

Here is what the CPU usage likes when Flow.exe is renamed and effectively disabled, but same tabs are open (CPU usage is low, and Firefox performs very well):

http://stevenrosenberg.net/documents/images/browsers/firefox/2019_0627_firefox_without_flow.jpg

I have this same issue with flow.exe and high CPU usage. I just want to add that the problem doesn't occur when using the Edge browser. When I start Firefox, almost immediately flow.exe starts using more CPU and the cooling fan starts going at a much faster rate. I tried renaming flow.exe but that just causes error messages when Windows 10 starts up. I have disabled CxMonSvc and CxUtilSvc in Services. However, I have to stop flow.exe in Task Manager every time I boot up. If you don't disable the 2 services above flow.exe will start up repeatedly when stopped.

(In reply to Steven Rosenberg from comment #5)

I don't see media.cubeb.backend in my about:config. All I have is media.cubeb.logging_level and media.cubeb.sandbox.

It's a hidden pref, so you need to "add" it as a string-type pref. Don't forget to delete it again after testing, you don't want to keep using the winmm backend as it's basically unsupported.

I am going to try to recreate this. I'm not sure that we have hardware around the office that will do it. But, I will try.

Has Conexant weighed in on anywhere, or are there contacts on their support/development team?

(In reply to Steven Rosenberg from comment #5)

(In reply to Matthew Gregan [:kinetik] from comment #3)

nsPIDOMWindowInner::IsPlayingAudio doesn't interact with the OS audio APIs directly, so I don't think that'd cause any problems related to this.

Reading through the HP forum thread, it sounds like this may be outside of our control. It's possible changing the way we interact with the OS audio APIs could help avoid this issue, but I don't know what Flow.exe is trying to do so it's hard to guess if a workaround is possible within Firefox without being able to reproduce/investigate this locally - I don't have access to any of the affected configurations.

For anyone who can reproduce this: it might be worth setting the pref "media.cubeb.backend" to "winmm", restarting Firefox, and seeing if that changes the behaviour of Flow.exe in any way - I'd be surprised if it did, but I don't have any other immediate suggestions.

I don't see media.cubeb.backend in my about:config. All I have is media.cubeb.logging_level and media.cubeb.sandbox.

I tried this (media.cubeb.backend winmm), and it had no effect.

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #11)

Has Conexant weighed in on anywhere, or are there contacts on their support/development team?

Conexant is now owned by Synaptics https://www.synaptics.com/

(In reply to Daryl from comment #8)

I have this same issue with flow.exe and high CPU usage. I just want to add that the problem doesn't occur when using the Edge browser. When I start Firefox, almost immediately flow.exe starts using more CPU and the cooling fan starts going at a much faster rate. I tried renaming flow.exe but that just causes error messages when Windows 10 starts up. I have disabled CxMonSvc and CxUtilSvc in Services. However, I have to stop flow.exe in Task Manager every time I boot up. If you don't disable the 2 services above flow.exe will start up repeatedly when stopped.

Before the last update or two from Conexant/Synaptics/HP, disabling CxMonSvc and CxUtilSvc seemed to work, but lately that hasn't been the case for me. Even stopping Flow.exe in the Task Manager doesn't work: It immediately starts again.

What's working for me now is renaming Flow.exe so the Conexant sound system can't find it. I rename as _Flow.exe, and then running Firefox is extremely smooth. Plus there are zero issues in regard to sound, so I'm not even sure what Flow.exe is supposed to do.

Component: Performance → Audio/Video
Whiteboard: [qf] → [qf:p2:resource]

I've just sent an email to Synaptics, but they don't have outward facing tech emails that I could find, so let's see if their press department can help me find someone to assist.

Any further thoughts here, :kinetik? It sounds like we're limited here by whatever Flow.exe is doing? If so, I think we should mark this stalled unless we can get in touch with the driver vendor.

Flags: needinfo?(kinetik)

I'm not sure. Without someone debugging how Flow.exe is interacting with Firefox, we don't know what's going on.
Maybe there's a Flow.exe related DLL we can blocklist from loading into our process?

Flags: needinfo?(kinetik)

Managed to get a response to Synaptics, but they suggested we reach out to HP on the basis that HP will be responsible for the driver for their systems:

each manufacturer is the supplier of the driver that supports their systems.

Marking this as stalled due to us needing external input regarding Flow. I'm going to see if I can get a point of contact for HP.

Keywords: stalled

Reached out to a few people at HP via LinkedIn. Will update if I hear back.

Priority: -- → P3

Steven did this work better before with older versions of Firefox not consuming CPU, or did you notice this right away?

Flags: needinfo?(stevenhrosenberg)
Priority: P3 → P2

I just filed bug 1569712 today thanks to a new Reddit thread. Their about:support was showing that Flow had instantiated a11y and is probably doing something bad. I asked the user to attempt to disable a11y services. If they can confirm that this fixed it, then I think we can safely dupe this over to bug 1569712 and take care of it in the a11y blocklist.

This should be fixed by bug 1569712.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(stevenhrosenberg)
Resolution: --- → DUPLICATE
Duplicate of bug: 1569712

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.

Keywords: stalled

Despite the indication that this problem is resolved, for me it is NOT!!! Every day, when I boot up my laptop, I go directly to the Task Manager and end the task. What a pain in the butt!!!

(In reply to Daryl from comment #23)

Despite the indication that this problem is resolved, for me it is NOT!!! Every day, when I boot up my laptop, I go directly to the Task Manager and end the task. What a pain in the butt!!!

Could you create a new bug to track the issue and link it here? Since this bug is closed we don't want to use it to track further investigation. When opening the new bug it would be helpful if you could navigate to about:support and copy the information there into the bug.

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