Echo pretty bad in my WebRTC App compared with Google Hangouts

[Antonis Tsakiridis]

Hello,

I have been doing some tests and seems that with the exact same setup (equipment and scenario) a peer to peer WebRTC call using our Web App with Chrome produces huge echo problems, while Google Hangouts works just fine. I realized, after checking webrtc-internals, that there are additional audio constraints passed from Google Hangouts so I figured this would be the issue. So I updated our gUM code to use the exact same constraints that Google Hangouts uses.

The problem is that even though I don't get any error when setting them, in the end, when I check in webrtc-internals/gUM screen, the values are totally different, plus some keys are missing. For example I see:

Audio Constraints

{advanced: [{googEchoCancellation: {exact: false}}, {googAutoGainControl: {exact: false}}, {googNoiseSuppression: {exact: false}}, {googHighpassFilter: {exact: false}}, {googAudioMirroring: {exact: false}}]}

While for Google Hangouts I scenario see:

Audio Constraints

{advanced: [{googEchoCancellation: {exact: true}}, {googExperimentalEchoCancellation: {exact: true}}, {googAutoGainControl: {exact: true}}, {googExperimentalAutoGainControl: {exact: true}}, {googNoiseSuppression: {exact: true}}, {googHighpassFilter: {exact: true}}, {googAudioMirroring: {exact: false}}, {googExperimentalNoiseSuppression: {exact: true}}, {deviceId: {exact: ["default"]}}]}

Any idea what might be the issue?

Here's my gUM call:

            getUserMedia({audio:

               {

                  advanced:

                  [

                     {googEchoCancellation: { exact: true }},

                     {googExperimentalEchoCancellation: {exact: true}},

                     {googAutoGainControl: {exact: true}},

                     {googExperimentalAutoGainControl: {exact: true}},

                     {googNoiseSuppression: {exact: true}},

                     {googHighpassFilter: {exact: true}},

                     {googAudioMirroring: {exact: false}},

                     {googExperimentalNoiseSuppression: {exact: true}},

                     {deviceId: {exact: ["default"]}}

                  ]}, video:false}, function(stream) { ... }, function(error) { ... });

Best regards,

Antonis Tsakiridis

[Antonis Tsakiridis]

Did some more tests and managed to amend the code, so that some keys are actually accepted (after restarting the browser too that for some reason didn't get latest state in webrtc-internals page):

getUserMedia({audio:

               {

                     googEchoCancellation: true,

                     googExperimentalEchoCancellation: true,  

                     googAutoGainControl: true, 

                     googExperimentalAutoGainControl: true, 

                     googNoiseSuppression: true, 

                     googHighpassFilter: true, 

                     googAudioMirroring: false, 

                     googExperimentalNoiseSuppression: true, 

                     deviceId: "default"

                  }, ...

The problem is that the keys that contain the 'Experimental' keyword don't seem to take effect:

Audio Constraints

{advanced: [{googEchoCancellation: {exact: true}}, {googAutoGainControl: {exact: true}}, {googNoiseSuppression: {exact: true}}, {googHighpassFilter: {exact: true}}, {googAudioMirroring: {exact: false}}]}

Is this to be expected? Could it be that experimental keys are for Google use only somehow?

Best regards,

Antonis

[Antonis Tsakiridis]

Ok so I managed to set the same gUM() audio constraint settings with Google Hangouts although the echo is still same and pretty bad :(. 

Any idea why two WebRTC Apps (i.e. Google Hangouts vs our web App) using the exact same audio constraints for the exact same environment and test scenario would behave so differently?

Best regards,

Antonis

[Eric Davies]

I would check to see if the hangout packets are going directly to the other peer or if they are actually going to a google server which may be doing some audio processing along the way.

[Antonis Tsakiridis]

Good point Eric, I went back to webrtc-internals and indeed it seems that there is a Google Media Server of some sort in between; the remote side for the selected candidate pair for each of the peers is a Google server. I guess I could potentially use webrtc-internals to retrieve the wave file that each side sends to the wire and see if there's echo there, right? 

If there is and the remote side can't hear it then it must be Google server side processing that fixes the situation.

Thanks a lot for the help!

[Philipp Hancke]

i'd also check the roundtriptime.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b0ae18c1-d8e2-4f88-9cec-4e13c4eb2f67%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Antonis Tsakiridis]

Sure, will check that as well thanks.

On Thu, May 11, 2017 at 6:41 PM, 'Philipp Hancke' via discuss-webrtc <discuss...@googlegroups.com> wrote:

i'd also check the roundtriptime.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/venWV0jgxeQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiKWXdkV9vzXxS-pLX1oP7%3DfEaY7t73dUzDaNApdoqO7Qw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Antonis Tsakiridis

Lead Developer, Mobile SDKs at Telestax

antonis.t...@telestax.com

http://www.telestax.com