Closed Bug 918056 Opened 11 years ago Closed 11 years ago

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


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

26 Branch
Gonk (Firefox OS)
Not set



blocking-b2g koi+
Tracking Status
firefox25 --- wontfix
firefox26 --- fixed
firefox27 --- fixed
b2g-v1.2 --- fixed


(Reporter: jsmith, Assigned: slee)




(1 file, 1 obsolete file)

Build: 9/17/2013 Master
Device: Buri


1. In tab #1 in the browser, go to
2. Select Audio
3. Grant permissions to your microphone
4. In tab #2 in the browser, go to
5. Select Audio
6. Grant permissions to your microphone


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


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.
Blocks: 894848
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.
blocking-b2g: --- → koi?
Blocks: b2g-getusermedia
No longer blocks: 894848
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.
blocking-b2g: koi? → koi+
Hi Randy,

Please take this one first and discuss it with Chien. Suggest denying the second request on user media during the triage.
Assignee: nobody → rlin
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?
Flags: needinfo?(slee)
Attached patch patch (obsolete) — Splinter Review
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.

Attachment #811850 - Flags: review?(rjesup)
Flags: needinfo?(slee)
Attachment #811850 - Flags: review?(rjesup) → review+
Here is the try server log.
* try: -b do -p all -u all -t none
Assignee: rlin → slee
Attached patch patchSplinter Review
update the patch summary
Attachment #811850 - Attachment is obsolete: true
Attachment #812471 - Flags: review+
Keywords: checkin-needed
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Keywords: verifyme
QA Contact: jsmith
This works for the two content case, but I think it regressed the three content case. See bug 923260 for a followup.
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.