Alon Zakai (:azakai) Reporter
	Description • 12 years ago

http://www.syntensity.com/static/bb/client.html

The game has some gc/recompilation pauses, every few seconds the frame rate drops. But aside from that, when you click to fire the gun, there is a very noticeable pause - longer and worse than the gc pauses - right after the sound plays, pretty much every time.

These are *NOT* gc pauses, no gc'ing shows up in the logs. Also, a CPU monitor with high frequency shows that the CPU is inactive during these pauses, as if sleeping as it waits for a lock or something like that. Commenting out the line that does .play() on the audio element prevents the stalls, so it seems to be audio related.

(If you want to comment it out, save a local copy of the html file and also the same url with .data instead of .html, that's all it needs. The relevant play() happens in _Mix_PlayChannel.)

	Alon Zakai (:azakai) Reporter
	Comment 1 • 12 years ago

Bill, this sounds similar to something we saw in the past on a (private) game-related demo, I seem to recall you profiled it and found audio is to blame, and when audio was disabled the demo got much faster? Do you remember any other details that might help here?

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 2 • 12 years ago

Yeah, the problem was that we were spending a lot of time waiting for a lock in the media code. It was a Linux-only problem, and the media people didn't seem to have much interest in fixing it. I'm not sure there's much that can be done.

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
	Comment 3 • 12 years ago

What lock are blocking on that can be held for ~seconds?

	Chris Pearce [:cpearce (Not reading bugmail)] Assignee
	Comment 4 • 12 years ago

(In reply to Bill McCloskey (:billm) from comment #2)
> Yeah, the problem was that we were spending a lot of time waiting for a lock
> in the media code.

What's the bug number for this?

If we're stuck waiting for several seconds on a lock, we'll want to fix that.

> It was a Linux-only problem, and the media people didn't
> seem to have much interest in fixing it. I'm not sure there's much that can
> be done.

Matthew Gregan has been in the process of writing our own sound library (libcubeb) which should alleviate much of our sound issues. It's been slow going, in part because sound on Linux is a pretty broken.

libcubeb has landed for Windows and Mac, but it's disabled on Aurora+ so we can test it more. Linux still needs work I understand, so hasn't landed.

	Alon Zakai (:azakai) Reporter
	Comment 5 • 12 years ago

(In reply to Chris Pearce (:cpearce) from comment #4)
> (In reply to Bill McCloskey (:billm) from comment #2)
> > Yeah, the problem was that we were spending a lot of time waiting for a lock
> > in the media code.
> 
> What's the bug number for this?
> 

Other people know more, but I suspect since the demo where we saw the problem was non-public, we couldn't open a bug on it.

But anyhow, we do have a usable testcase now in this bug.

	Chris Pearce [:cpearce (Not reading bugmail)] Assignee
	Comment 6 • 12 years ago

This is easy to fix. We're holding the decoder monitor when we write silence to the audio stream in order to ensure we've written more than the block size in AudioLoop(), and that's blocking event runners acquiring the monitor on the main thread.

	Chris Pearce [:cpearce (Not reading bugmail)] Assignee
	Comment 7 • 12 years ago

In addition to holding the media decoder monitor while writing silence to fill up the last block in the stream, we're *not* holding the monitor while reading mState and mStopAudioThread; we should be.

Tests pass locally, I've pushed to Try:
https://tbpl.mozilla.org/?tree=Try&rev=6c8fb3cdfeb5

I'll upload a `diff -w` patch, so it's clearer what I've changed.

	Chris Pearce [:cpearce (Not reading bugmail)] Assignee
	Comment 8 • 12 years ago

Same as previous patch, but produced with `diff -w`, so it's clearer what's going on.

	Chris Pearce [:cpearce (Not reading bugmail)] Assignee
	Comment 9 • 12 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/e103eee2cc24

	(no longer active)
	Comment 10 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/e103eee2cc24

	Alon Zakai (:azakai) Reporter
	Comment 11 • 12 years ago

Works great, thanks for the quick resolution!