WebRTC seems to have its own audio API abstraction layer, which means that (empirically verified) it doesn't benefit from the interprocess remoting prototyped in bug 1391523 and continuing in bug 1362223. This is going to block the same sandboxing goals as bug 1362220. In particular, we can't achieve a meaningful level of sandboxing on Linux as long as we have to allow PulseAudio in content processes.

I took a closer look at this. It seems as if we should be using cubeb for both input and output, because the media.navigator.audio.full_duplex pref is true[1]. But we don't get there; on line 312 we call VoEBaseImpl::Init, which calls into webrtc::AudioDevice stuff: #7 0x00007f1a86fb7504 in pa_context_new_with_proplist () at /usr/lib/x86_64-linux-gnu/libpulse.so.0 #8 0x00007f1a99bd2ac1 in webrtc::AudioDeviceLinuxPulse::InitPulseAudio() (this=0x7f1a88f3f400) at /home/jld/src/gecko-dev/media/webrtc/trunk/webrtc/modules/audio_device/linux/audio_device_pulse_linux.cc:2074 … #11 0x00007f1a99bddaa0 in webrtc::AudioDeviceModule::Create(int, webrtc::AudioDeviceModule::AudioLayer) (id=65635, audio_layer=webrtc::AudioDeviceModule::kPlatformDefaultAudio) at /home/jld/src/gecko-dev/media/webrtc/trunk/webrtc/modules/audio_device/audio_device_impl.cc:102 #12 0x00007f1a99a87dd2 in webrtc::VoEBaseImpl::Init(webrtc::AudioDeviceModule*, webrtc::AudioProcessing*, rtc::scoped_refptr<webrtc::AudioDecoderFactory> const&) (this=0x7f1a89d311d0, external_adm=0x0, audioproc=0x0, decoder_factory=...) at /home/jld/src/gecko-dev/media/webrtc/trunk/webrtc/voice_engine/voe_base_impl.cc:197 #13 0x00007f1a9883cc47 in mozilla::MediaEngineWebRTC::EnumerateAudioDevices(mozilla::dom::MediaSourceEnum, nsTArray<RefPtr<mozilla::MediaEngineAudioSource> >*) (this=0x7f1a88f1c5e0, aMediaSource=<optimized out>, aASources=0x7f1a83cd05c8) at /home/jld/src/gecko-dev/dom/media/webrtc/MediaEngineWebRTC.cpp:312 #14 0x00007f1a986b0193 in mozilla::media::LambdaTask<mozilla::MediaManager::EnumerateRawDevices(uint64_t, mozilla::dom::MediaSourceEnum, mozilla::dom::MediaSourceEnum, bool)::<lambda()> >::Run(void) (media_device_name=0x7f1a9bb0b8b4 <gNullChar> "", aResult=nsTArray<RefPtr<mozilla::AudioDevice> > &, aEnumerate= &virtual mozilla::MediaEngine::EnumerateAudioDevices(mozilla::dom::MediaSourceEnum, nsTArray<RefPtr<mozilla::MediaEngineAudioSource> >*), aSrcType=mozilla::dom::MediaSourceEnum::Microphone, engine=0x7f1a88f1c5e0) at /home/jld/src/gecko-dev/dom/media/MediaManager.cpp:1330 :jesup, do you know if there's a way to avoid the upstream webrtc code trying to use its own audio device layer like this? [1] https://searchfox.org/mozilla-central/rev/18c16ebf818abb86805ce08a6e537e4cd826f044/dom/media/webrtc/MediaEngineWebRTC.cpp#319 (also line 367)

This is being worked on in bug 1385258 (first step) and we're also going to do a large refactoring to use newer WebRTC API (we're using a very old API that is not supported and we're running into all sorts of trouble). I expect to be done with this before audio remoting is finished.

Hey Paul, curious, do we need to switch away from old webrtc.org audio interfaces/code for all platforms or just Linux?

We don't need to "switch", we're already not using them. We need to stop using old and deprecated interfaces for echo cancelation/noise cancelation/etc. from webrtc.org, that have the side effect of using the webrtc.org audio device abstractions. This applies to all platform I think.

Mass change P2->P3 to align with new Mozilla triage process.

Just a quick note that this will be fixed in bug 1397793. I have a patch set that I need to test more, locally, that makes us not initialize the audio_device module of webrtc.org.

bug 1397793 has been fixed, this should work now.

I've verified (using https://mozilla.github.io/webrtc-landing/pc_test.html) that WebRTC now works when the content process is blocked from connecting to PulseAudio. Thank you!