Closed Bug 1715502 Opened 4 years ago Closed 4 years ago

Flaky sound when browser is playing in the background

Categories

(Core :: DOM: Content Processes, defect, P2)

Firefox 91
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr78 --- unaffected
firefox89 --- unaffected
firefox90 --- affected
firefox91 --- affected

People

(Reporter: davydm, Assigned: mccr8)

References

(Regression)

Details

(Keywords: regression, regressionwindow-wanted)

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

Steps to reproduce:

Similar to (perhaps regression from?) https://bugzilla.mozilla.org/show_bug.cgi?id=1524193

This time it's much easier to reproduce: I made a recording here: https://recordit.co/cjpwNbjbrN

  • playing sound on SoundCloud: the tab starts out as background priority (even when focused)
  • I up the priority to Normal, switch to another tab, switch back to Process Explorer: tab priority is back at Background
  • I up the priority there to Normal again, switch back to the tab... and it's back as Background

When using Firefox to play music in the background, whenever my programming tooling starts getting a little active, sound gets really choppy - understandable since the tab has been prioritised as Background (and I've seen it drop down to Idle too)

Actual results:

Sound playback becomes choppy when the system is under load and the browser is backgrounded

Expected results:

Sound should be silky-smooth, carrying me through my work tasks :D

As requested by :gsvelto in the original thread, I'm asking for more info from :mccr8

Flags: needinfo?(continuation)

Linked original report and potential regressor to the see also section(for tracking).

See Also: → 1524193
See Also: → 1618547
Status: UNCONFIRMED → NEW
Ever confirmed: true

What version of Firefox are you using? About when did you start noticing this issue? In about:support, do you have any entries under "Fission Windows" (I want to know if Fission is enabled or not)? Thanks.

I'm going to assume this is a recent issue, so it is almost certainly a regression from bug 1618547.

Component: Untriaged → DOM: Content Processes
Flags: needinfo?(continuation) → needinfo?(davydm)
Keywords: regression
Product: Firefox → Core
Regressed by: 1618547
See Also: 1618547
Has Regression Range: --- → yes
Assignee: nobody → continuation

Firefox version: Firefox Nightly 91.0a1 (2021-06-08) (64-bit)
Started happening over the last few days (that I've noticed)
about:support / Fission Windows says: "0/1 Disabled by default"

Flags: needinfo?(davydm)

(FYI, you can add priority as a column in Process Explorer to make it a bit easier to track.)

I wasn't able to reproduce this issue on Windows 10 in an up-to-date version of Nightly. I started the browser, went to the front page of Sound Cloud (I'm not logged in), pressed play. The process for Sound Cloud has normal priority. When I switched away from the tab (pinned or not) the priority remained normal. If I paused the playing, then the priority would drop as expected when switching away.

I suppose I need to try it with Fission disabled or with more Sound Cloud tabs. Maybe there's some issue when a background tab shares the same process as the Sound Cloud tab. I think we're not testing that scenario.

Were you manually adjusting the priority of processes before you saw the issue? Another possibility is that the manual priority changing is confusing things somehow.

I tried testing some more scenarios:

  • Fission enabled, two Sound Cloud tabs (one playing audio, one not), then switching between various tabs.
  • Fission disabled, a dozen or so unrelated tabs open (to cover all of the processes), then swapping between one of the unrelated tabs while audio was playing in a Sound Cloud tab.

I didn't see any unexpected behavior.

Can you figure out, from a freshly started browser, some steps that get to the initial state in comment 0? In other words, where you have Sound Cloud open in a foreground tab and it doesn't have normal priority. Thanks.

Flags: needinfo?(davydm)

re-watching my own video, I'm actually not sure if it doesn't rather show a bug in process explorer: whilst the context-menu "selected priority" shifts each time, the Priority column stays steady at 8. There are only three possibilities:

  1. context menu is correct (my original assumption)
  2. priority column is correct (which would point to no defect)
  3. both are incorrect (so I guess I should modify my renice watcher to output what it altered the priority from, and report back when I can see that showing the behavior I assumed was happening)

The experienced result was real though: stuttering sound under moderate load (I have an hexacore, ht-enabled machine, process explorer was showing usage at around 30%). I accept that I need to find more concrete reproduction steps if I'm to be of any assistance here.

Trying in a clean Nightly profile, I neither saw the changes whilst switching around, nor, after altering process priority with the same Process Explorer version, saw inconsistencies between the context menu and the priority column :|

Flags: needinfo?(davydm)

Set release status flags based on info from the regressing bug 1618547

You could try setting dom.ipc.processPriorityManager.enabled to false in about:config and restart and see if that helps the audio issue. That might let us confirm the priority manager theory.

Another line of investigation, if you are comfortable doing something a bit more involved, would be to use MozRegression to bisect when the issue started happening. You'll want to set it up to use a copy of your profile or something.

In addition, would you mind having a look in regedit.exe at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\Tasks ? There should be a few things like "Audio", "Pro Audio", etc., normally.

And if you can reproduce this at will would you mind taking a media profile? It's really simple, this video shows how: https://blog.paul.cx/post/profiling-firefox-media-workloads/#the-media-preset

Flags: needinfo?(davydm)

Does the problem happen when playing music on a site other than SoundCloud?

If you can reliably reproduce the bug, it would be a big help if you could use the MozRegression utility to test some older Firefox Nightly builds to pinpoint when the problem started:

https://mozilla.github.io/mozregression/

Severity: -- → S3
Priority: -- → P2
QA Whiteboard: [qa-regression-triage]

I don't play music on a lot of sites, tbh - SoundCloud or YouTube (but only sometimes). More often than not, I youtube-dl content so I can listen without wasting bandwidth or requiring a connection, especially since I live in South Africa where electricity continuity isn't guaranteed.

I've only noticed this issue on SoundCloud though.

As before, I've never been able to reliably reproduce the issue - when I think I have steps to repro, then it refuses to happen. I'm also not sure if this hasn't been inadvertently fixed in between when I re-raised it and now. I've modified my renicer to allow watching only & logging to file, so I'm leaving that running for a while to see if I can at least see the problem still happening. To be honest, in the last week or two that I can remember, I haven't experienced the issue, but I'm not sure if I'm simply not performing the correct steps to provoke it.

Flags: needinfo?(davydm)

This is probably obvious, but in leaving my tool running, watching process priority on the soundcloud tab, I notice that if I stop music play and switch away from the tab, it's immediately set to Idle priority (I'm sure that's on purpose) and the priority bumps up if I mouse-over the tab title (to check on the pid), and then bumps back down again; is there perhaps a way that the priority could get stuck at Idle during one of these operations? I did try to "trick" things by:

  1. having js in the console start playback after I'd left the tab unfocused for some time (couldn't catch it out: priority goes down to idle but is bumped immediately when playback starts again)
  2. muting the tab: priority drops after a while, but raises immediately when I unmute.

So if I'm not able to repro right now, it's certainly not for lack of trying :D

Hi Davyd!
I was unable to reproduce it on latest Nightly 91.0a1 on windows 10.
Did you have the chance to run mozregression as mentioned in Comment 12?
Thanks!

Flags: needinfo?(davydm)

Hi Marcela

No, sorry, I haven't had the time and I'm not sure I will get the time, tbh. This is a thing that has been very tricky to repro at the best of times, and Nightly has been behaving for quite a while now. I really just don't have the time to run through a proper mozgression on this, sorry ):

I'm happy to close this out and re-raise if I see it again.

Flags: needinfo?(davydm)

Hi Davyd,
Thanks for your reply, I will close this as Resolved WFM based on your comment.
Please feel free to reopen it if you can still reproduce this.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.