1096717 - e10s sandbox breaks audio playback

Status: RESOLVED DUPLICATE of bug 1042735

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

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

Somehow e10s is breaking playback of audio tracks in MP4 files.

This is a showstopper.

STR:
1. Load http://people.mozilla.org/~cpearce/video/avatar.mp4 in an e10s Nightly Firefox build.
2. Observe video playing, but no audio comes out speakers.

If you disable e10s, the audio track plays as expected.

Comment 1

[Matthew Gregan [:kinetik]]

One data point: on Linux (x86_64 build, Fedora 20) with the current Nightly with e10s enabled, I *do* get audio playing with that file with both the GStreamer (default) and MP4Reader/ffmpeg (disable media.gstreamer.enabled and enable media.fragmented-mp4.exposed and media.fragmented-mp4.ffmpeg.enabled).

Comment 2

[Matthew Gregan [:kinetik]]

Audio is also working for me on avatar.mp4 in current Nightly (x86 build) on Windows 8.1.

Comment 3

[Chris Peterson [:cpeterson]]

cpearce: what platform are you testing?

avatar.mp4 audio works correctly for me on OS X with e10s.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

I was testing on my Win 8.1 x64 desktop with an up to date Nightly. Re-testing now on my Win8.1 x64 laptop, audio in MP4 works. There could be something specific related to my desktop machine, I will test when I get into the office tomorrow. If I connect to my desktop via VPN, HW acceleration is disabled, and that takes e10s with it.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

OK, this must be an issue with my profile. If I start Nightly on my desktop with a new clean profile, audio works, but using the existing profile, it doesn't and playback is slow to start...

Comment 6

[Chris Peterson [:cpeterson]]

This bug is necessary for basic playback of EME video on Windows.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

I see the following in the logs when I load Firefox with the bad profile:

Unable to initialize audio client: 80070006.
[Child 8080] WARNING: AudioStream::OpenCubeb() ef8d9e0 failed to init cubeb: file c:\Users\cpearce\src\mozilla\purple\dom\media\AudioStream.cpp, line 513
[Child 8080] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file c:\Users\cpearce\src\mozilla\purple\dom\media\AudioStream.cpp, line 393
[Child 8080] WARNING: Initializing AudioStream failed.: file c:\Users\cpearce\src\mozilla\purple\dom\media\AudioSink.cpp, line 155

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

The hr code is E_HANDLE; Invalid Handle.

Comment 9

[Matthew Gregan [:kinetik]]

Thanks for the logs, that does confirm a libcubeb stream failed to initialize, but I have no idea why it failed.  E_HANDLE isn't a documented error code for IAudioClient::Initialize.  We're not passing anything like a HANDLE in to Initialize as far as I can see, and if there was a problem with the IAudioClient (stm->client) you'd expect http://mxr.mozilla.org/mozilla-central/source/media/libcubeb/src/cubeb_wasapi.cpp#704 to fail (or the first use, where GetMixFormat is called).

I do notice in the docs:

    Note: In Windows 8, the first use of IAudioClient to access the audio device should be on the STA
          thread. Calls from an MTA thread may result in undefined behavior.

I'm a bit fuzzy on the STA/MTA stuff, but I'm not sure we do anything special to ensure this requirement is fulfilled.

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

STA/MTA is a MSCOM thing... IIUIC threads which init MSCOM in STA mode assume single thread access, and so don't do locking in the refcounting of COM objects, whereas MTA assume multi-threadded, and lock their refcounts.

We init MSCOM in MTA mode for all threads in our SharedThreadPools, but the Gecko main thread runs STA.

I still don't understand how this profile causes cubeb init to fail, but a fresh profile succeeds... Maybe a fresh profile inits cubeb on the main thread whereas with this profile that doesn't happen? Possibly due to a theme or addon?

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

I copied the bad profile into my Win7 VM and I get the same behaviour. I tested with Nightly builds, so I don't have logging here.

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

That is, I get no audio with e10s enabled in this profile on Win7. So it's not a Win8 specific issue.

Comment 13

[Matthew Gregan [:kinetik]]

Spun off a new bug about the (now confirmed as unrelated) libcubeb/COM stuff.

Chris gave me a copy of his profile and I was able to reproduce this locally.  During debugging, I noticed the plugin-container was running in low rights mode.  That led me to the pref "browser.tabs.remote.sandbox", which was set to "warn" in this profile.  Resetting it to the default, "off", restored audio.

I wonder what we need to do to allow audio to work from the sandbox?

Comment 14

[Chris Pearce [:cpearce (Not reading bugmail)]]

Ah interesting! I set "browser.tabs.remote.sandbox" to "warn" because I was told it would produce warnings when the sandbox blocked prohibited behaviour, in the hope that this also worked for Gecko Media Plugins.

I don't think this bug needs to block EME or MSE tracking bugs now that we've determined that it's not going to affect profiles with prefs set to defaults.

Comment 15

[Matthew Gregan [:kinetik]]

Bob, do you know what we might need to do to allow audio via WASAPI to work from the sandbox?

If this is eventually going to require remoting to the chrome process, I'd like to have this on someone's radar sooner rather than later since it'll require a decent amount of work to implement properly -- our last attempt for the Android audio remoting was extremely rushed and not very successful.

Comment 16

[Bob Owen (:bobowen)]

(In reply to Matthew Gregan [:kinetik] from comment #15)
> Bob, do you know what we might need to do to allow audio via WASAPI to work
> from the sandbox?
> 
> If this is eventually going to require remoting to the chrome process, I'd
> like to have this on someone's radar sooner rather than later since it'll
> require a decent amount of work to implement properly -- our last attempt
> for the Android audio remoting was extremely rushed and not very successful.

This looks like another manifestation of bug 1042735.
Yes, it is going to need remoting to the chrome or possibly another new process.
gcp, jesup - we discussed this a few weeks ago, I suspect that you may not have had any time to look at this yet.
Will you be tracking it via bug 1042735 or a different bug?

(In reply to Chris Pearce (:cpearce) from comment #14)
> Ah interesting! I set "browser.tabs.remote.sandbox" to "warn" because I was
> told it would produce warnings when the sandbox blocked prohibited
> behaviour, in the hope that this also worked for Gecko Media Plugins.

Yeah, even the "warn only" sandbox, which basically punches as many holes as possible through the sandbox, didn't allow this to work, which is why we decided we'd have to move this.

As for logging on GMP.
I've got a list of things to land, which are blocked by some reviews at the moment, but once bug 928044 lands you should be able to get logging for the GMP sandbox.
You set an env var (MOZ_WIN_SANDBOX_LOGGING=1) and it will log in debug when things are blocked by the sandbox.
There is a pref that you can use as well for the content process, but using the pref for GMP was painful.

Comment 17

[Gian-Carlo Pascutto [:gcp]]

I've filed desperate bugs to track the media sandboxing work.

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Can this bug still be replicated on 46 and 47?

Comment 19

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Looks like this is Windows-specific.

Comment 20

[Bob Owen (:bobowen)]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #18)
> Can this bug still be replicated on 46 and 47?

I think this was essentially fixed when fixing bug 1119878 meant we could start the sandbox at low integrity.

Certainly the MP4 in the Description plays with audio for me now.