636755 - Slight slowdown with setInterval when system volume is changed

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Grant Galitz]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre

Firefox seems to delay setInterval badly for a duration of a half a second a second after changing the volume up or down on Snow Leopard 10.6.6.

Not a bad bug at all, but quite a mysterious one indeed. I work around the bug by producing extra audio samples to make sure the audio stays gapless during the slowdown, so I could care less for now.

Reproducible: Always

Steps to Reproduce:
1. Load a .gb or .gbc ROM file into the emulator.
2. Make sure audio in on.
3. Change your volume once the game is running.
Actual Results:  
Weird slight slowdown that occurs one second after changing the volume and lasts for about a second.

Expected Results:  
No slowdown.

Happens with any GameBoy or GameBoy Color ROM binary as far as I know.

Comment 1

[Grant Galitz]

I changed the URL above to a page that automatically loads a ROM in.
http://www.grantgalitz.org/gameboy/ is the page that has the user load in a ROM.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I can't reproduce on the URL in the url field.  Is that deploying the workaround you mention in comment 0, or does it actually show the bug for you?

Comment 3

[Grant Galitz]

That workaround is actually a feature that kicks in when firefox is max'd out and CPU usage is at 100%. The weird thing about this bug is that CPU usage *goes down* when the volume changes, causing the slowdown.

Comment 4

[Grant Galitz]

It deploys the workaround, but you'll notice the ROM goes in slo-mo (sounds that way too) for a second and you'll notice a drop in CPU usage by approx. 10% (that's what the diff was on my macbook pro.).

Comment 5

[Boris Zbarsky [:bzbarsky]]

> but you'll notice the ROM goes in slo-mo (sounds that way too)

I don't see that effect.

Comment 6

[Grant Galitz]

Here are my specs to see if this helps one bit:
  System Version:	Mac OS X 10.6.6 (10J567)
  Kernel Version:	Darwin 10.6.0
  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro7,1
  Processor Name:	Intel Core 2 Duo
  Processor Speed:	2.4 GHz
  Number Of Processors:	1
  Total Number Of Cores:	2
  L2 Cache:	3 MB
  Memory:	4 GB
  Bus Speed:	1.07 GHz

Comment 7

[Grant Galitz]

I'll get a better testcase that has a more stable CPU usage over time, so the drop is clearer. Yeah, the emulation doesn't stop, but there's definitely a slowdown at least on my comp that seems to stem from setInterval timing being wrong or something (Like as if there's another process holding it up from working normally). I want to be clear and say this is not important, but a very unusual thing to have going on indeed.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> but there's definitely a slowdown at least on my comp

My point is that I do NOT see that happening at all over here.

I'd love to see a testcase that actually shows the problem!

Comment 9

[Grant Galitz]

A more stable test ROM in terms of average CPU usage over time: http://www.grantgalitz.org/gtfo/SMB_TEST/index.php

Any drop in CPU usage should be more easily discernible with that ROM, since it holds its average load on the CPU better.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Url in comment 9 is 404.

Comment 11

[Grant Galitz]

Sorry about that, I did some directory cleaning.

Try http://grantgalitz.org/shantae/

Comment 12

[Boris Zbarsky [:bzbarsky]]

Can't reproduce there either....

Comment 13

[Grant Galitz]

Happens with other mac os x programs. It seems Mac OS X interferes with timing of programs in this case in general. Not an exclusive bug to Firefox. Weird interruption from the system though.

Comment 14

[Grant Galitz]

The test URL is back up. Took down these other links again. Damn, I really should stop deleting folders all the time on my server...

Comment 15

[Grant Galitz]

I'd recommend this as a won't fix just because it seems like an obscure OS bug that's hard to even tell that it even exists.

Comment 16

[Grant Galitz]

Still happens with the nightly and stable

Comment 17

[Grant Galitz]

Still happens, but it seems it's the OS rather mucking with stuff. The OS reduces timer resolution on-demand messing up firefox timer logic.

Comment 18

[Wayne Mery (:wsmwk)]

(In reply to Grant Galitz from comment #17)
> Still happens, but it seems it's the OS rather mucking with stuff. The OS
> reduces timer resolution on-demand messing up firefox timer logic.

invalid based on this comment