Closed
Bug 1276136
Opened 9 years ago
Closed 8 years ago
no voice path for a basic call
Categories
(Core :: WebRTC, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: anil.alk27, Unassigned, NeedInfo)
Details
(Whiteboard: [needinfo 2016/05/26 to reporter] )
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.63 Safari/537.36
Steps to reproduce:
make a basic webrtc audio call.
Actual results:
No voice path. Instead we are hearing cranky Noise.
Expected results:
Voice path on both the ends should be fine.
Comment 1•9 years ago
|
||
Please provide specific steps to reproduce, or this isn't actionable.
Flags: needinfo?(anil.alk27)
| Reporter | ||
Comment 2•9 years ago
|
||
As per our previous comments from https://bugzilla.mozilla.org/show_bug.cgi?id=1213773,
When you file this new bug, can you include the following in the new bug report?:
1) What microphone or audio input device are you using?
****** I am using laptop's default microphone(inbuilt).
2) What OS (or OSs) are you testing on? (Mac, Windows, Linux?)
****** Windows 7
3) Do you get the same noise when you try our gUM demo here: https://mozilla.github.io/webrtc-landing/gum_test.html? (Just click on Audio or Audio & Video)
****** No. Voice path is fine
4) Can you try versions 46, 47 and 48 of Firefox? 46 is our current release version, 47 is in Beta, 48 will be going to Beta in less than 2 weeks.
****** tried in v46.0.1 and voice path is fine.
5) Using Nightly (from 05-25 or from today), can you go to about:config, search for "full_duplex", and flip the pref with "full_duplex" in the title from true to false and retest?
****** Tested in v49.0a1 (2016-05-26)of nightly. Now voice path seems to be fine after changing the "full_duplex" config item to false in about:config. I tried to reproduce this issue by changing the "full_duplex" back to true , but still the voice path is fine.
Not quite sure what was causing this problem previously.
Thanks.
Flags: needinfo?(mreavy)
Comment 3•9 years ago
|
||
(In reply to Anil Kumar from comment #2)
> As per our previous comments from
> https://bugzilla.mozilla.org/show_bug.cgi?id=1213773,
>
> When you file this new bug, can you include the following in the new bug
> report?:
> 1) What microphone or audio input device are you using?
> ****** I am using laptop's default microphone(inbuilt).
We need to know *what* hardware the microphone is (see various data in Control Panel). Also, deep in the Control Panel entries for the mic, what set of sample rates and stereo/mono it supports (usually in a dropdown that lets you change them).
>
> 2) What OS (or OSs) are you testing on? (Mac, Windows, Linux?)
> ****** Windows 7
>
> 3) Do you get the same noise when you try our gUM demo here:
> https://mozilla.github.io/webrtc-landing/gum_test.html? (Just click on
> Audio or Audio & Video)
> ****** No. Voice path is fine
That *strongly* implies the mic is ok, and getUserMedia is ok.
>
> 4) Can you try versions 46, 47 and 48 of Firefox? 46 is our current release
> version, 47 is in Beta, 48 will be going to Beta in less than 2 weeks.
> ****** tried in v46.0.1 and voice path is fine.
>
> 5) Using Nightly (from 05-25 or from today), can you go to about:config,
> search for "full_duplex", and flip the pref with "full_duplex" in the title
> from true to false and retest?
> ****** Tested in v49.0a1 (2016-05-26)of nightly. Now voice path seems to be
> fine after changing the "full_duplex" config item to false in about:config.
> I tried to reproduce this issue by changing the "full_duplex" back to true ,
> but still the voice path is fine.
>
> Not quite sure what was causing this problem previously.
So is this problem still happening? It isn't clear from the above comments. Also, anything that changing full_duplex helps should also have shown up in gum_test.html.
A useful test might be to run whatever app is having the problem, provoke the problem, and then in another tab run gum_test and see if that appears to get audio.
If this is somewhere after gum, we'll need more info about the overall chain that gives bad audio.
>
> Thanks.
Comment 4•9 years ago
|
||
Thanks, Anil, for reporting this and needinfo'ing me. We are very interested in getting to the bottom of what's going on, but we need more info. If you can answer the questions from Randell in comment 3, that would help a lot. Also, is it possible to get a recording (from an external device) of the problem you're hearing? If that's not feasible, can you describe the exact audio problem you're hearing? (e.g. Is there "static" or are there lots of pops/clicks?)
Lastly, can you test DevEdition (Fx48) and tell me if that is good or bad? If that is bad, can you test with Beta (Fx47)?
Thanks again for helping us to debug this.
Flags: needinfo?(mreavy)
Updated•9 years ago
|
Whiteboard: [needinfo 2016/05/26 to reporter]
| Reporter | ||
Comment 5•9 years ago
|
||
Till now i did not face any problem with the voice path. So i think after updating my nightly and changing "full_duplex" config it is fine. If i face this issue again, will collect all the information you asked and report it to you.
Thanks guys.
Flags: needinfo?(anil.alk27)
Comment 6•9 years ago
|
||
(In reply to Anil Kumar from comment #5)
> Till now i did not face any problem with the voice path. So i think after
> updating my nightly and changing "full_duplex" config it is fine. If i face
> this issue again, will collect all the information you asked and report it
> to you.
>
> Thanks guys.
ok, but I'm concerned about the "full_duplex" comment. We're moving to all-full-duplex - does it work with full_duplex set to 'true' (default in Nightly), or with it set to 'false', or both? Note you may need to restart the browser after changing the variable (to be safe; it might not be needed but let's not risk confusion).
Flags: needinfo?(anil.alk27)
Comment 7•8 years ago
|
||
Nothing actionable here.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•