Closed Bug 1524193 Opened 2 years ago Closed 2 years ago

Flaky sound on youtube and overcast.fm

Categories

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

67 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla67
Tracking Status
firefox-esr60 --- unaffected
firefox65 --- unaffected
firefox66 --- unaffected
firefox67 --- verified

People

(Reporter: rinkevics, Assigned: mconley, NeedInfo)

References

Details

(Keywords: regression)

Attachments

(4 files)

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

Steps to reproduce:

Listen to sound on https://overcast.fm/+FgGOsF_P8 and youtube.com
Using firefox nightly

Actual results:

When CPU usage was high due to activity by other applications, sound was intermittently disappearing/appearing.

Expected results:

There should not be interruptions in the sound.

Attached file trobleshoot_data.txt

Is this something new with the nightly or do you have the same problem with Firefox64/65 release builds ?

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

This happens only on nightly. Release 65 works fine.

Could you try to find the change in Firefox that caused this with the mozregression tool ?
That tool downloads a few nightly builds and let you test them.

Flags: needinfo?(rinkevics)

will try that

Flags: needinfo?(rinkevics)

Any ideas Paul?

Flags: needinfo?(padenot)

Regression tool does not work because of proxy connection issues.

Can repro, mozregression shows that the problem is bug 1476981

With dom.ipc.processPriorityManager.enabled set to false the problem dissapears

Blocks: 1476981
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Depends on: 1523974
Flags: needinfo?(padenot)

Setting priority here although it looks like the fix will happen in Bug 1523974.

Rank: 15
Priority: -- → P2

Hi rinkevics - we just landed a patch in Nightly that slightly raises the process priority of background tabs that are playing audio. Do you still hear the dropped audio if you try to reproduce in today's Nightly?

Flags: needinfo?(rinkevics)
Duplicate of this bug: 1526869

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

I can still reproduce the issue.

Thanks, Alice. How about with this try build?:

32-bit: https://queue.taskcluster.net/v1/task/a6_aMdKgR-CROx3z48zPsA/runs/0/artifacts/public/build/target.zip

64-bit: https://queue.taskcluster.net/v1/task/QLycC4IDSPCAFyqM2xVi4w/runs/0/artifacts/public/build/target.zip

padenot ^-- perhaps you can see if these also pass the test you ran earlier?

Flags: needinfo?(padenot)
Flags: needinfo?(alice0775)

(In reply to Mike Conley (:mconley) (:⚙️) from comment #14)

Thanks, Alice. How about with this try build?:

32-bit:
https://queue.taskcluster.net/v1/task/a6_aMdKgR-CROx3z48zPsA/runs/0/
artifacts/public/build/target.zip

64-bit:
https://queue.taskcluster.net/v1/task/QLycC4IDSPCAFyqM2xVi4w/runs/0/
artifacts/public/build/target.zip

padenot ^-- perhaps you can see if these also pass the test you ran earlier?

Yes, the try build fixed the issue.

Flags: needinfo?(alice0775)

The issue persists in 67.0a1 (2019-02-11)
But the issue is also observed in the latest public release.
I sometimes have the same issue (sound disappearing intermittently) in Chrome but much much less.

Flags: needinfo?(rinkevics)

(In reply to rinkevics from comment #17)

This build is the same:
32-bit: https://queue.taskcluster.net/v1/task/a6_aMdKgR-CROx3z48zPsA/runs/0/artifacts/public/build/target.zip
64-bit: https://queue.taskcluster.net/v1/task/QLycC4IDSPCAFyqM2xVi4w/runs/0/artifacts/public/build/target.zip

Will try to run same workload on another, more powerful PC tonight.

What is your machine? On a release build, sound should be absolutely flawless, so this indicate another possible issue.

Flags: needinfo?(padenot) → needinfo?(rinkevics)
Attached file systeminfo.txt
Flags: needinfo?(rinkevics)

I attached systeminfo output. Do you need anything else?

I also have Kaspersky antivirus is quite heavy.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #14)

Thanks, Alice. How about with this try build?:

32-bit: https://queue.taskcluster.net/v1/task/a6_aMdKgR-CROx3z48zPsA/runs/0/artifacts/public/build/target.zip

64-bit: https://queue.taskcluster.net/v1/task/QLycC4IDSPCAFyqM2xVi4w/runs/0/artifacts/public/build/target.zip

padenot ^-- perhaps you can see if these also pass the test you ran earlier?

As I mentioned briefly on IRC, my slow machine that I used to test this doesn't boot anymore, so I'm afraid I can't test this. I hope to have another machine soon.

However, it should fix it, based on reading some documentation.

It's perfect, thanks. (In reply to rinkevics from comment #20)

I attached systeminfo output. Do you need anything else?

No, it's perfect, thanks.

Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cea0ec7278c1
Make audio wakelocks put background tabs into the normal priority bucket. r=gsvelto
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Assignee: nobody → mconley
Flags: qe-verify+

Managed to reproduce the issue; however when trying to verify the fix, the flaky-ness reappeared on macOS(10.13).
Fwiw, on Ubuntu the issue did not seem to appear.
As suggested by :mconley on Slack, will open a separate bug for the above mentioned issue(bug 1546064).

Fix verified with 67.0b12 Windows 10 - 20 minutes session of trying to reproduce.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

I'm experiencing this issue on Firefox Nightly 75.0a1 (2020-03-02) (64-bit) on SoundCloud. This particularly hits when the host machine is under load (eg building .net solution)

Opening process explorer and finding the process for this tab, I can see that it's set to low-priority. Raising to "High" makes music buttery-smooth again.

(In reply to Davyd McColl from comment #28)

I'm experiencing this issue on Firefox Nightly 75.0a1 (2020-03-02) (64-bit) on SoundCloud. This particularly hits when the host machine is under load (eg building .net solution)

Opening process explorer and finding the process for this tab, I can see that it's set to low-priority. Raising to "High" makes music buttery-smooth again.

Davyd, this is windows I assume? Mike, anything changed on your side of things?

Flags: needinfo?(mconley)
Flags: needinfo?(davydm)

Paul, correct, Windows 10, build 1909 (OS Build 18364.657)

Flags: needinfo?(davydm)

Hi David,

Do you have Fission enabled?

Flags: needinfo?(mconley) → needinfo?(davydm)

Not on my windows machine at the moment, but
(a) only just learned about (non-nuclear) Fission
(b) doesn't seem to be enabled by default on my Gentoo box
(C) there are about 10 flags I see in about:config when I search for Fission - what should I enable?

Flags: needinfo?(davydm) → needinfo?(mconley)

If you've not enabled Fission manually yourself, then I don't think we need to worry about it - I wanted to check if you'd opted into testing it.

Are you able to reproduce the same issue on Firefox Beta or Release?

Flags: needinfo?(mconley) → needinfo?(davydm)

I've just installed Firefox 73.0.1 (64-bit) and I'll see how that goes today. A question though: Firefox nightly shows the PID of the tab in the tooltip for the tab, so it's easy to find in, eg Process Explorer (which is where I saw that my soundcloud tab was set to low priority). Firefox current doesn't do this -- is there a way to figure it out? about:performance doesn't seem to show me, and, with one tab open, Process Explorer shows 4 Firefox processes, so I'm not sure which one relates to the tab?

Flags: needinfo?(davydm)

Ok, so, after running for a while, and figuring out I could just watch process explorer to see which new process a new tab belonged to:

  1. I have noticed stuttering under heavy load with firefox stable
  2. I see that process for the new tab I opened is running backgrounded (https://postimg.cc/mPzKqHQ5)

Would you like me to install and test with beta too?

Blocks: 1621684

Has anyone had a moment to look into this? Listening to SoundCloud today was really frustrating, whilst WebStorm and Rider were eating up CPU. The only resolution was to manually bump the tab's process priority via ProcessExplorer, but that doesn't stick, so I have to periodically bump process priority.

Please can this get some <3 ?

(In reply to Davyd McColl from comment #36)

Has anyone had a moment to look into this? Listening to SoundCloud today was really frustrating, whilst WebStorm and Rider were eating up CPU. The only resolution was to manually bump the tab's process priority via ProcessExplorer, but that doesn't stick, so I have to periodically bump process priority.

Please can this get some <3 ?

Mike, I thought you had fixed this and written a test, why are we still seeing this? Davyd, please attach the result of going to about:support and getting the raw data with the button for this at the top of the page.

Flags: needinfo?(mconley)
Flags: needinfo?(davydm)
Attached file about_rawdata.json

about:support data, as requested.

Flags: needinfo?(davydm)

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

Mike, I thought you had fixed this and written a test

I had, and I did.

why are we still seeing this?

Unsure. Davyd, do you have some reliable steps-to-reproduce where the background tab playing audio has lower process priority?

Flags: needinfo?(mconley) → needinfo?(davydm)

Power just went out in my area, so please bear with a short response from my phone.

I just noticed sound stuttering today, opened process explorer and set priority to real-time -stuttering stopped (big hammer, I know). Switched away, and a little time later looked again at process explorer - the set-priority submenu marks the current process priority and I noticed it was back down to idle/background, so I boosted it again.

Flags: needinfo?(davydm)

And this background tab was running SoundCloud?

Flags: needinfo?(davydm)

Correct, with audio playing.

Flags: needinfo?(davydm)

Hey Rares,

Is it possible for someone at SV to help try to reproduce Davyd's issue / generate some STR? I'm having no luck reproducing locally. If we can find some STR, then let's get a new bug on file and get this sorted.

Flags: needinfo?(rares.bologa)
Flags: needinfo?(rares.bologa) → needinfo?(clara.guerrero)

Hi Mike

I think I may have steps to repro (at least, two or three runs though, this seemed to work for getting the reduced priority, however, after a few more attempts, it stopped, so perhaps there's some kind of race condition I was "lucky" to encounter earlier, and which I manage to encounter at least once or twice a day?)

  1. SoundCloud is running pinned, playing music
  2. Open one or more new, empty tabs
  3. Navigate a new tab to www.google.com
  4. Switch away to another window (in my case, it was WebStorm)
  5. Switch back
  6. Close the new tab with www.google.com in it

after doing this, the process priority for my soundcloud tab had been bumped to background / idle

It's not a perfect repro tho -- like I say, this worked around 3 times in a row, and then I couldn't get it to happen again ): Is there perhaps some code which, upon closing a tab, attempts to figure out what else could be cleaned up, and potentially adjusts process priorities?

All priority adjustments happen in the ProcessPriorityManager. It relies upon a bunch of events to decide when to lower or raise the priority of a given process. BTW how many tabs did you had open when you reproduced the issue?

About 7 pinned tabs and anywhere between 1 and 20 regular tabs. I often "close all to right" when tabs start being scrollable.

Alright so we might have more than one tab per process. The process priority manager was originally designed for Firefox OS and thus assumed that we had always only one tab per process. It might be that its logic is buggy when more than one tab is shared by the same process.

I'll reduce the number of content processes in my local setup and try again to reproduce.

Hey Davyd,

I've tried your STR, and a number of alternative configurations, and I'm still not able to reproduce this.

Would you be able to do and post a screen capture so that we can see you walking through your steps and reproducing the bug? That might make it easier for me to see what I'm missing here.

Flags: needinfo?(davydm)
You need to log in before you can comment on or make changes to this bug.