918056 - Requesting gUM audio across two distinct content processes allows playback of the first stream, but not the second

Status: VERIFIED FIXED

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

Description

[Jason Smith [:jsmith]]

Build: 9/17/2013 Master
Device: Buri

STR

1. In tab #1 in the browser, go to http://mozilla.github.io/webrtc-landing/gum_test.html
2. Select Audio
3. Grant permissions to your microphone
4. In tab #2 in the browser, go to http://mozqa.com/qa-testcase-data/webapi/webrtc/gum_test.html
5. Select Audio
6. Grant permissions to your microphone

Expected

If we're allowing the microphone to be used across multiple content processes in gUM audio, then I'd expect playback to occur for mozilla.github.io & mozqa.com. If only one content process can get access to gUM audio at a time, then I'd expect HARDWARE_UNAVAILABLE to fire in mozqa.com after step #5.

Actual

After step #3, the audio controls will playback the gUM audio stream. However, after step #6, the audio controls will halt at 0:00 with the gUM audio stream acquired.

Additional Notes

The same issue can also be seen if you try to request gUM audio between a browser tab and an app.

Comment 1

[Jason Smith [:jsmith]]

At a minimum, we should be throwing HARDWARE_UNAVAILABLE if fixing sharing a mic across content processes in too much work. Having the mic be used across distinct processes probably isn't a critical issue. For the first piece, I'm nominating to block.

Comment 2

[Jason Smith [:jsmith]]

Triage - we decided meeting the use case in comment 1 was the minimum to meet here as the 1.2 blocking criteria. The multiple distinct processes support is not a blocker and can be taken as a followup.

Comment 3

[Ivan Tsay (:ITsay)]

Hi Randy,

Please take this one first and discuss it with Chien. Suggest denying the second request on user media during the triage.

Comment 4

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

This bug comes from b2g can't open the 2nd recording instance in back-end
==
E/AudioHardwareMSM76XXA(  118): More than one instance of recording not supported
E/AudioRecord(  983): Could not get audio input for record source 1
E/libOpenSLES(  983): android_audioRecorder_realize(0x44705400) error creating AudioRecord object
==
So the gUM should raise the HARDWARE_UNAVAILABLE if gonk layer throw error.
Hi Steven, Could you help check this?

Comment 5

[StevenLee[:slee]]

Attachment: patch

This bug is resulted from that when users try to create the second MediaEngineWebRTCAudioSource, the init function fails at [1]. After that, MediaManager tries to allocate the mic resource and returns at [2]. It should return error then the applications can get informed.

[1] http://dxr.mozilla.org/mozilla-central/source/content/media/webrtc/MediaEngineWebRTCAudio.cpp#l278
[2] http://dxr.mozilla.org/mozilla-central/source/content/media/webrtc/MediaEngineWebRTCAudio.cpp#l116

Comment 6

[StevenLee[:slee]]

Here is the try server log.
* try: -b do -p all -u all -t none
** https://tbpl.mozilla.org/?tree=Try&rev=2fa38398fd68

Comment 7

[StevenLee[:slee]]

Attachment: patch

update the patch summary

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/c62f55756420

Comment 9

[Ryan VanderMeulen [:RyanVM]]

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

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/ee2954428768

Comment 11

[Jason Smith [:jsmith]]

This works for the two content case, but I think it regressed the three content case. See bug 923260 for a followup.