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.
Definitely a regression.
Interestingly enough, this does not happen in the opposite scenario - integrated mic request for audio.
QA Wanted to test on Mac OS X and a different windows box.
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!
(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 - 188.8.131.52 * Plantronics .Audio 646 DSP - 6.1.7601.17514
Assignee: jsmith → nobody
Jason, Have you ever seen this bug on another machine? Do you see this bug when using Chrome Canary?
Assignee: nobody → 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.
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
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
I'll investigate if it reproduces on Chrome but I strongly doubt it will.
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 :(.
Oh wait, error on my end. Disregard...
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.
(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).
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
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?
(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.
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.
QA Wanted to get logs.
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 '=')
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: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.