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

RESOLVED INVALID

Status

()

Core
WebRTC: Audio/Video
P2
normal
RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: jsmith, Assigned: jesup)

Tracking

({regression})

Trunk
All
Windows 7
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [getUserMedia], [blocking-gum+])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
Created attachment 689299 [details]
Testcase
(Reporter)

Comment 2

5 years ago
Definitely a regression.
Keywords: regression
(Reporter)

Comment 3

5 years ago
Interestingly enough, this does not happen in the opposite scenario - integrated mic request for audio.
(Reporter)

Comment 4

5 years ago
QA Wanted to test on Mac OS X and a different windows box.
Keywords: qawanted
(Assignee)

Updated

5 years ago
Assignee: nobody → jsmith
(Assignee)

Updated

5 years ago
Whiteboard: [getUserMedia], [blocking-gum+]
(Assignee)

Comment 5

5 years ago
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!
(Reporter)

Comment 6

5 years ago
(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
Assignee: jsmith → nobody
Keywords: qawanted
Jason, Have you ever seen this bug on another machine?  Do you see this bug when using Chrome Canary?
Assignee: nobody → jsmith
Keywords: qawanted
(Reporter)

Comment 8

5 years ago
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.
Summary: Requesting audio access with gum with a USB mic + integrated mic for the USB mic - both input sources become active → Requesting audio access with gum to a USB input source makes all input sources active
(Reporter)

Comment 9

5 years ago
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.
Assignee: jsmith → nobody
Keywords: qawanted
(Reporter)

Comment 10

5 years ago
I'll investigate if it reproduces on Chrome but I strongly doubt it will.
(Reporter)

Comment 11

5 years ago
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 :(.
(Reporter)

Comment 12

5 years ago
Oh wait, error on my end. Disregard...
(Reporter)

Comment 13

5 years ago
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.
(Reporter)

Comment 14

5 years ago
(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).
(Assignee)

Comment 15

5 years ago
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
(Assignee)

Comment 16

5 years ago
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?
(Assignee)

Updated

5 years ago
Assignee: nobody → rjesup
(Assignee)

Updated

5 years ago
Priority: -- → P2
(Reporter)

Comment 17

5 years ago
(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.
(Assignee)

Comment 18

5 years ago
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.
(Reporter)

Comment 19

5 years ago
QA Wanted to get logs.
Keywords: qawanted
(Reporter)

Comment 20

5 years ago
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 '=')
(Reporter)

Comment 21

5 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Keywords: qawanted
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.