818992 - Requesting audio access with gum to a USB input source makes all input sources active

Status: RESOLVED INVALID

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

Description

[Jason Smith [:jsmith]]

Steps:

1. Load the attached test case with a USB + integrated mic hooked in
2. Request access to gum audio with the USB mic

Expected:

Only the USB mic should be a valid input source.

Actual:

Both the USB + integrated mics become valid input sources. Definitely a regression.

Comment 1

[Jason Smith [:jsmith]]

Attachment: Testcase

Comment 2

[Jason Smith [:jsmith]]

Definitely a regression.

Comment 3

[Jason Smith [:jsmith]]

Interestingly enough, this does not happen in the opposite scenario - integrated mic request for audio.

Comment 4

[Jason Smith [:jsmith]]

QA Wanted to test on Mac OS X and a different windows box.

Comment 5

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

Still have only seen this on one machine; if anyone else sees this please note here.  Jason, can you give the specs on the machine, OS version, audio input drivers and versions?  Also, if possible, use the Windows settings stuff to verify the mics all appear to be working correctly.  Thanks!

Comment 6

[Jason Smith [:jsmith]]

(In reply to Randell Jesup [:jesup] from comment #5)
> Still have only seen this on one machine; if anyone else sees this please
> note here.  Jason, can you give the specs on the machine, OS version, audio
> input drivers and versions?  Also, if possible, use the Windows settings
> stuff to verify the mics all appear to be working correctly.  Thanks!

Sorry for the delayed response. I can still reproduce on my machine on 1/24.

OS version: Windows 7 64-bit
Processor: Intel Core i7-2820QM CPU @ 2.30 GHz 2.30 GHz
Audio Input Drivers:

* Conexant 20672 SmartAudio HD - 8.32.23.5
* Plantronics .Audio 646 DSP - 6.1.7601.17514

Comment 7

[Maire Reavy [:mreavy]]

Jason, Have you ever seen this bug on another machine?  Do you see this bug when using Chrome Canary?

Comment 8

[Jason Smith [:jsmith]]

Going to try a different machine, but I just tried a different audio input device and saw similar behavior - looks like if you request access to any USB device, all input sources become active. So this might not be hardware specific.

I doubt this is a parity issue with Chrome, but I'll check that.

Comment 9

[Jason Smith [:jsmith]]

This bug also apparently reproduces on a different machine on OS X 10.7. I strongly doubt this is a parity issue with Chrome, cause I have a strong hunch this is an issue with our devices API. The fact that you can request access to USB mic A and get access to USB mic A, USB mic B, and integrated mic implies likely a bug our own API.

Comment 10

[Jason Smith [:jsmith]]

I'll investigate if it reproduces on Chrome but I strongly doubt it will.

Comment 11

[Jason Smith [:jsmith]]

Well...Chrome's implementation apparently is quite buggy - on Canary, I'm getting the blob, but no sound. Probably can't do a comparison then :(.

Comment 12

[Jason Smith [:jsmith]]

Oh wait, error on my end. Disregard...

Comment 13

[Jason Smith [:jsmith]]

Testing on Chrome Canary, it looks like they do something entirely different than us - they default to all input devices at all times. There's no way to specify an input device.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #13)
> Testing on Chrome Canary, it looks like they do something entirely different
> than us - they default to all input devices at all times. There's no way to
> specify an input device.

Or maybe there's a bug on Canary, as I'm seeing the same issue with the USB camera (no UI to select which device).

Comment 15

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

They no longer provide a UI for selecting the device..... an odd decision, but...

This may indeed make it tough to test.  You could change the 'default' device between calls to GetUserMedia

Comment 16

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

I just tested this with a USB headset on OSX 10.7.  I only get audio input from the selected device.

Perhaps some other software running on the system is interfering?  Skype?

"This bug also apparently reproduces on a different machine on OS X 10.7" - who was this?  Can I get MediaManager:5 or webrtc_trace:65535 logs from you and this person?

Comment 17

[Jason Smith [:jsmith]]

(In reply to Randell Jesup [:jesup] from comment #16)
> I just tested this with a USB headset on OSX 10.7.  I only get audio input
> from the selected device.
> 
> Perhaps some other software running on the system is interfering?  Skype?
> 
> "This bug also apparently reproduces on a different machine on OS X 10.7" -
> who was this?  Can I get MediaManager:5 or webrtc_trace:65535 logs from you
> and this person?

Can you clarify how I would get these logs? A debug build? A pref?

Juan (another QA) was the person who reproduced this on his OS X Macbook.

Comment 18

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

Debug build, NSPR_LOG_MODULES=mediamanager:5,webrtc_trace:65535 WEBRTC_TRACE_FILE=/tmp/webrtc.log NSPR_LOG_FILE=/tmp/nspr.log

Extremely weird...  Tried selecting every device offered (default(headset), internal, headset).  No problem.

Comment 19

[Jason Smith [:jsmith]]

QA Wanted to get logs.

Comment 20

[Jason Smith [:jsmith]]

Notes from Randell:

NSPR Logs

jesup	jsmith: from a command line (assuming bash), do "NSPR_LOG_MODULES=signaling:5,mediapipeline:5 NSPR_LOG_FILE=/tmp/nspr.log ./firefox -P webrtc -no-remote" (as an example, assuming you have a 'webrtc' profile)
	jesup	or use "export NSPR_LOG_MODULES=whatever", similar for NSPR_LOG_FILE, and then just "./firefox -P webrtc -no-remote"
	jesup	in tcsh, it's "setenv NSPR_LOG_MODULES signaling:5" (note: no '=')

Comment 21

[Jason Smith [:jsmith]]

This is invalid. I actually figured out this was a mistake on my end. Here's why:

The sound generating from "snapping my fingers," even being far away, still traveled over to my headset in a smaller amount. So I think this was a screwup on my end. Sorry for all of the confusion.