Closed
Bug 1307754
Opened 8 years ago
Closed 7 years ago
Webrtc. FF Beta 50.0b4. No signal from microphone.
Categories
(Core :: WebRTC: Audio/Video, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla53
People
(Reporter: roudakov.michael, Assigned: jesup)
References
Details
Attachments
(6 files, 1 obsolete file)
728 bytes,
text/html
|
Details | |
9.23 KB,
image/png
|
Details | |
9.09 KB,
image/png
|
Details | |
40.99 KB,
image/png
|
Details | |
80.66 KB,
image/png
|
Details | |
1.14 KB,
patch
|
padenot
:
review+
jcristau
:
approval-mozilla-aurora+
gchang
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Steps to reproduce: Simple sequence: - call GetUserMedia() - set LocalMediaStream to Audioplayer Full html+js code attached as loop.html Actual results: Windows 10, 64-bit The microphone can not be heard in the headset for: - Beta 50.0b4(Win64) - Nightly 52.0a1 (2016-10-04) (64-bit) But, for release 47.0.1 - All Ok. microphone can be heard. Also, for tasks with real connection, microphone can not be heard from FF beta and nightly. Additional: Set of devices in "Share" dialog is different for Release and Beta/Nigtly versions.
I can't reproduce it, with FF50 or 52, I can hear myself when speaking after sharing the microphone.
Reporter | ||
Comment 2•8 years ago
|
||
(In reply to Loic from comment #1) > I can't reproduce it, with FF50 or 52, I can hear myself when speaking after sharing the microphone. Win 10 x64?
Reporter | ||
Comment 3•8 years ago
|
||
FF47 sharing dialog has 5 devices
Reporter | ||
Comment 4•8 years ago
|
||
FF50 sharing dialog has 4 devices
Reporter | ||
Comment 5•8 years ago
|
||
Audio devices in Device Manager
(In reply to roudakov.michael from comment #2) > (In reply to Loic from comment #1) > > I can't reproduce it, with FF50 or 52, I can hear myself when speaking after sharing the microphone. > > Win 10 x64? Win 7 64b.
Updated•8 years ago
|
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Assignee | ||
Comment 7•8 years ago
|
||
Can you try setting media.navigator.audio.full_duplex to false in about:config? What audio device is it? If you choose a a different device, does it work better? DO you see the same problem with the "Audio" button on https://mozilla.github.io/webrtc-landing/gum_test.html? Thanks!
Flags: needinfo?(roudakov.michael)
Whiteboard: [Needinfo 2016/10/7 to reporter]
Reporter | ||
Comment 8•8 years ago
|
||
> Can you try setting media.navigator.audio.full_duplex to false in about:config? media.navigator.audio.full_duplex = true Nightly - Silent. (4 devices) Beta - Silent. (4 devices) Release(47) - Charsh (565dab23-5f2e-4646-a2ec-98ff82161010) (https://crash-stats.mozilla.com/report/index/565dab23-5f2e-4646-a2ec-98ff82161010) media.navigator.audio.full_duplex = false Nightly - Ok. (5 devices; Acoustic on 1-st and 5-st devices) Beta - Ok. (5 devices; Acoustic on 1-st and 5-st devices) Release(47) - Ok. (5 devices; Acoustic on 1-st and 5-st devices) > What audio device is it? If you choose a a different device, does it work better? - Internal audio - NVidia see AudioDevices.png (attached) I went through all of the devices. Silent for Nightly and Beta. (before changing media.navigator.audio.full_duplex) > DO you see the same problem with the "Audio" button on https://mozilla.github.io/webrtc-landing/gum_test.html? Same sympthoms.
Comment 9•8 years ago
|
||
Ball is back to you.
Flags: needinfo?(roudakov.michael) → needinfo?(rjesup)
Whiteboard: [Needinfo 2016/10/7 to reporter] → [needinfo jesup 10/11]
Assignee | ||
Comment 10•8 years ago
|
||
Paul - can you check? Michael (Reporter) - can you run it, starting firefox from a command window with set MOZ_LOG=GetUserMedia:4,MediaManager:4 set MOZ_LOG_FILE=some temp file for logging and attach the logs here? Thanks for helping debug this!
Flags: needinfo?(roudakov.michael)
Flags: needinfo?(rjesup)
Flags: needinfo?(padenot)
Whiteboard: [needinfo jesup 10/11] → [needinfo padenot, reporter 10/11]
Reporter | ||
Comment 11•8 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #10) > Michael (Reporter) - can you run it, starting firefox from a command window > with > set MOZ_LOG=GetUserMedia:4,MediaManager:4 > set MOZ_LOG_FILE=some temp file for logging > > and attach the logs here? Thanks for helping debug this! Empty log file: -Media sharing dialog confirmed -Nigtly,Beta -media.navigator.audio.full_duplex true and false -start command line as user and as adminstrator I found https://wiki.mozilla.org/Media/WebRTC/Logging set NSPR_LOG_MODULES=MediaManager:5,GetUserMedia:5. set NSPR_LOG_FILE=c:/!/z/nightly-fullduplex-true.log But same result: emtpy log file Any other logging flags?
Flags: needinfo?(roudakov.michael)
Comment 12•8 years ago
|
||
It's unclear to me why there is no log here. Maybe a path issue ? What's with the '!' in the path ? Also we've added a new log that can be useful, "cubeb:4". Can you please try on a nightly, from https://nightly.mozilla.org/ ?
Flags: needinfo?(padenot) → needinfo?(roudakov.michael)
Reporter | ||
Comment 13•8 years ago
|
||
> Can you please try on a nightly, from https://nightly.mozilla.org/ ?
set MOZ_LOG=GetUserMedia:4,MediaManager:4,cubeb:4
set MOZ_LOG_FILE=d:\Users\nightly-fullduplex-true.log
firefox.exe
Empty log files: nightly-fullduplex-true.log; nightly-fullduplex-true.log.child-1
Additional info:
When I disable all recoring audio devices except connected microphone, test works properly in "Nigtly".
Flags: needinfo?(roudakov.michael)
Comment 14•8 years ago
|
||
Hmm, that might be my device index fix from the other day (Bug 1312413). Michael, how many devices have you plugged in? We see four or five devices, and they seem to be duplicates, what is your exact setup ?
Flags: needinfo?(roudakov.michael)
Reporter | ||
Comment 15•8 years ago
|
||
(In reply to Paul Adenot (:padenot) from comment #14) > Hmm, that might be my device index fix from the other day (Bug 1312413). Near. MediaEngineWebRTC.cpp auto j = mDeviceNames->IndexOf(devices->device[i]->device_id); if (j != nsTArray<nsCString>::NoIndex) { // match! update the mapping (*mDeviceIndexes)[j] = i; } else { // new device, add to the array mDeviceIndexes->AppendElement(i); mDeviceNames->AppendElement(devices->device[i]->device_id); =====> I think, j should be reassigned here ========================================== } if (devices->device[i]->preferred & CUBEB_DEVICE_PREF_VOICE) { // There can be only one... we hope NS_ASSERTION(mDefaultDevice == -1, "multiple default cubeb input devices!"); mDefaultDevice = j; } New stuff in Nightly 53.0a1 (2016-11-16): After refresh page - correct list of devices. Acoustic is correct. I think, it is because mDeviceNames already loaded Nightly_53.0a1_(2016-11-16)_(64-bit).png But, Beta 51.0b1 (64-bit) do not show correct devices list after refresh and do not route acoustic from all devices in list > Michael, how many devices have you plugged in? We see four or five devices, > and they seem to be duplicates, what is your exact setup ? Plugged only microphone in front side jack and speakers in backplain jack. Microphone and speaker on internal sound board. List of devices attached as AudioDevices2.png
Flags: needinfo?(roudakov.michael)
Reporter | ||
Comment 16•8 years ago
|
||
Attachment #8798060 -
Attachment is obsolete: true
Reporter | ||
Comment 17•8 years ago
|
||
Comment 18•8 years ago
|
||
jesup, does comment 15 makes sense for you? You know more this code that I do.
Flags: needinfo?(rjesup)
Assignee | ||
Comment 19•8 years ago
|
||
Thanks! j is always -1 (noindex) without this patch in the first time we enumerate, and -1 happens to be interpreted as 'not set', which means the first entry in the list
Attachment #8812530 -
Flags: review?(padenot)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → rjesup
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(rjesup)
Assignee | ||
Updated•8 years ago
|
Whiteboard: [needinfo padenot, reporter 10/11]
Assignee | ||
Updated•8 years ago
|
Rank: 12
Priority: -- → P1
Assignee | ||
Comment 20•7 years ago
|
||
Comment on attachment 8812530 [details] [diff] [review] Set default device index properly on first enumeration Approval Request Comment [Feature/regressing bug #]: bug 1312413 [User impact if declined]: Default device incorrect on first load [Describe test coverage new/current, TreeHerder]: manual - requires device changes [Risks and why]: no risk. Needed as follow-on to bug 1312413 which just landed on beta (and is on aurora due to uplift) [String/UUID change made/needed]: none
Attachment #8812530 -
Flags: approval-mozilla-beta?
Attachment #8812530 -
Flags: approval-mozilla-aurora?
Updated•7 years ago
|
Attachment #8812530 -
Flags: review?(padenot) → review+
Comment 21•7 years ago
|
||
Pushed by paul@paul.cx: https://hg.mozilla.org/integration/mozilla-inbound/rev/4dc5c5cf427d Set default device index properly on first enumeration. r=padenot
Comment 22•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4dc5c5cf427d
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox53:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Updated•7 years ago
|
status-firefox51:
--- → affected
status-firefox52:
--- → affected
Comment 23•7 years ago
|
||
Comment on attachment 8812530 [details] [diff] [review] Set default device index properly on first enumeration webrtc fix for aurora52
Attachment #8812530 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 24•7 years ago
|
||
Comment on attachment 8812530 [details] [diff] [review] Set default device index properly on first enumeration Fix a WebRTC issue related to device detection. Beta51+. Should be in 51 beta 6.
Attachment #8812530 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 25•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/ceda318fb493
Comment 26•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/166d234f600f
Updated•7 years ago
|
Flags: qe-verify+
Comment 27•7 years ago
|
||
Tested on Windows 10 x64 and I can't reproduce this, I've tried with Nighty old build(2016-10-04) and with a new build(2016-12-28). Tested on Windows 7 x32 with Nighlty 53.0a1(2016-12-28) and I can confirm the fix.
Comment 28•7 years ago
|
||
I reproduced this issue using 51.0b4, build ID: 20161128075558, on Windows 10 x64. I can confirm this issue is fixed, I verified using Fx 51.0b10, build ID: 20161222080852 and Fx 52.0a2, build ID: 20161228004005 on Windows 10 x64. Cheers!
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in
before you can comment on or make changes to this bug.
Description
•