802399 - Cannot select across the listed microphones when requesting gUM audio - all of them become active input sources, rather than the one mic selected

Status: VERIFIED FIXED

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

Description

[Jason Smith [:jsmith]]

Steps:

1. Request audio from gUM with an integrated mic and a USB mic
2. When the permission prompt appears, select the USB mic
3. Put the MediaStream given into an audio tag and start playing it
4. Generate sounds into the integrated mic and USB mic

Expected:

The device's speakers should only be sending sound out from the USB mic.

Actual:

The device's speakers send sound out from both the integrated and USB mics.

Comment 1

[Dão Gottwald [:dao]]

Sounds like bug 797796 isn't working as expected, unless the front-end is sending bogus data to the back-end.

Comment 2

[Jason Smith [:jsmith]]

(In reply to Dão Gottwald [:dao] from comment #1)
> Sounds like bug 797796 isn't working as expected, unless the front-end is
> sending bogus data to the back-end.

Okay. I was debating on this one specifically if it's front-end or core.

Anant - Can you confirm this is a core issue?

Comment 3

[Anant Narayanan [:anant]]

Looks like a core issue, we'll take a look.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

I think this is fixed from my local testing

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Attachment: set capture index for audio input when device is Allocate()ed

Further testing shows we were selecting the last device in the list always.  This used to always be the first device on linux and mac, which is the 'default' device, due to another bug.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 681845 [details] [diff] [review]
set capture index for audio input when device is Allocate()ed

I left the SetRecordingDevice() in Init() to verify it can record; may not really be needed.

Comment 7

[Anant Narayanan [:anant]]

Hmm, this might be tricky. Since we're using the same engine, if I call Allocate() on another object, then the device index gets changed. Would it be better if we move to SetRecordingDevice call to Start()?

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Even worse: capture microphone 1 in tab 1.  Capture microphone 2 in tab 2.  What microphone data does each see?

(was just trying this to test another bug; it doesn't work of course)

Comment 9

[Timothy B. Terriberry (:derf)]

Comment on attachment 681845 [details] [diff] [review]
set capture index for audio input when device is Allocate()ed

Review of attachment 681845 [details] [diff] [review]:
-----------------------------------------------------------------

Stealing review at jesup's request.

::: content/media/webrtc/MediaEngineWebRTCAudio.cpp
@@ +52,5 @@
>    if (mState != kReleased) {
>      return NS_ERROR_FAILURE;
>    }
>  
> +  webrtc::VoEHardware* ptrVoEHw = webrtc::VoEHardware::GetInterface(mVoiceEngine);

If you call GetInterface(), you need to call Release().

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Attachment: set capture index for audio input when device is Allocate()ed

Also plugs an existing leak of ptrVoEHw in ::Init()

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5444aff38dfb

FF17/18 are unaffected by this bug because it was introduced shortly after last uplift (other than the leak)

Comment 12

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/5444aff38dfb

Comment 13

[Jason Smith [:jsmith]]

Verified on 11/19.

Comment 14

[Jason Smith [:jsmith]]

If we could fake the devices, we might be able to automate this. Although as it stands in the current framework, we don't have this ability. Putting in-testsuite- for now, although if device faking becomes possible at some point, then we should re-evaluate this one for a test.