OSX and Echo

[Michael Graves]

Hi All,

Here at ZipDX we have a WebRTC-based soft phone that runs in Chrome. We have a particular use case (simultaneous interpretation) that requires that one person on a call both listen and speak at the same time. They hear English (for example) and speak in Spanish.

Echo cancellation in Chrome historically mangles audio when there's double-talk. The situation described above means that this participant is in constant double-talk.

No problem. We make the interpreter wear a headset, and we disable echo cancellation for their instance of Chrome. Problem solved.

That arrangement works great on Windows, Linux and Chromebooks. However, on OSX it doesn't work at all. Interpreters using Chrome on OSX always introduce massive echo into the call.

We use the exact same audio constraints in setting up an interpreter, regardless of platform. Why would a user on a Mac be so problematic? Where can I look to gain some insight into this matter?

Of course, Apple is no help at all as soon as they learn that it's a web app that won't run in Safari. If it can't be debugged in Safari they won't even talk about it.

Many thanks,

Michael Graves

[Michael Graves]

I had a conversation with someone in tech support at Plantronics today. He advised that the matter of echo with respect to OSX is a known bug in the current release of Sierra. He opened a ticket but advised that the solution would eventually come from Apple in the next update to the OS.

[Brant Jameson]

Hi,

   Since you've disabled echo cancellation, you should be aware that any echo present will not be removed.  Headsets are not a panacea for echo; many headsets still have some acoustic (and mechanical) coupling between the speaker and microphone, and as such, can cause echo.  Some headsets are better than others in this regard.  A few suggestions to help us troubleshoot your issue:

1.) Please provide the complete details of your setup.  IE What headset are you using?  What volume (both mic and speaker) are you operating the headset at?

2.) Can you capture some audio logs from the echoic endpoint and attach them to this message?  A short guide on how to do so: https://tokbox.com/blog/how-to-get-a-webrtc-diagnostic-recording-from-chrome-49/ . Please be sure to actually capture a sample which contains the problematic echo.  It will also be helpful if the audio logs contain some double-talk.  A quick suggestion would be to collect ~30s of echo at the start of the call (aka far-talk) and then another ~30s of double-talk.

  Some additional suggestions:

1.) Try re-enabling the echo canceller while using your headset.  The amount of suppression (what you've called 'mangling') inserted by the AEC will depend on the strength of the echo path.  Since you're using a headset, you should have a relatively weak echo path, and thus very little suppression (aka 'mangling').

2.) Try using a nice, well isolated headset like the Sennheiser SC-60 (https://en-us.sennheiser.com/call-center-office-headset-usb-sc-60-usb-ml).  This headset has virtually no echo path.

-Brant

[Michael Graves]

Brant,

Thank you for the reply. Before we get into the details let me say that I come from a background of broadcasting & recording studios, along with twenty years of SIP/VoIP.

1.) Please provide the complete details of your setup.  IE What headset are you using?  What volume (both mic and speaker) are you operating the headset at?

Mac Mini running Sierra & current Chrome stable. Our WebRTC app sets Chrome to enable AGC, so the mic level varies with activity. The listening level is "sensible" which looks like about 70% of the allowed range in OSX.

I've used a dozen different headsets: Logitech H110 analog , Logitech H650 USB, Sennheiser IP 550 USB, VXi Passport 21 with analog (3.5mm TRRS) bottom cable, VXi Passport 21 with USB bottom cable.

We are clear about identifying a little echo, induced via acoustic or mechanics means. When we have the problem the echo is dramatically louder. Loud enough to stop conversation. It's clearly induced by signal manipulation, not something acoustic or mechanical.

 

2.) Can you capture some audio logs from the echoic endpoint and attach them to this message?  A short guide on how to do so: https://tokbox.com/blog/how-to-get-a-webrtc-diagnostic-recording-from-chrome-49/ . Please be sure to actually capture a sample which contains the problematic echo.  It will also be helpful if the audio logs contain some double-talk.  A quick suggestion would be to collect ~30s of echo at the start of the call (aka far-talk) and then another ~30s of double-talk.

I will attempt this. I should note that Google themselves admitted the behavior of the EC was a problem. It wasn't a bug, but a matter of it's design. This is, at least in part, why we will soon see a whole new AEC3 released in M59. If AEC3 does a better job we may be able to turn EC back on for interpreters.

 

  Some additional suggestions:

1.) Try re-enabling the echo canceller while using your headset.  The amount of suppression (what you've called 'mangling') inserted by the AEC will depend on the strength of the echo path.  Since you're using a headset, you should have a relatively weak echo path, and thus very little suppression (aka 'mangling').

We'e done this already. It's how we determined that it was necessary to disable EC for interpreters. In the normal flow of conversation a little unwanted suppression is acceptable, since it only happens occasionally when someone talks over someone else.

For an interpreter who is continuously in double-talk it's very bad. It renders their delivery unacceptable to their client.

 

2.) Try using a nice, well isolated headset like the Sennheiser SC-60 (https://en-us.sennheiser.com/call-center-office-headset-usb-sc-60-usb-ml).  This headset has virtually no echo path.

I just took delivery of a new Sennheiser SC series headset today, but I've got a closet of them from Jabra, Logitech, Panasonic, Plantronics, Sennheiser & VXi, 

We do believe that the paths are isolated in the headset. I recently reverted my test bed Mac from Sierra (10.1.12) to El Capitan (10.1.11.) When I did that the problems completely disappeared.

[Brant Jameson]

Hi Michael,

   Interesting feedback.  I was not aware that AEC3 was going to change the functional operation of the AEC algorithm.  My understanding was that it was supposed to reduce memory consumption and make the code a bit easier to follow (some of the far end ring buffer manipulation and delay estimation is pretty convoluted and difficult to understand).  Sounds like you have a better handle on the issue than I had assumed.  I would be curious to see audio logs from the two versions of OSX that you've tried to use and perhaps a link to any forum or article in which google discusses this particular issue.

Appreciate the response,

-Brant

On Tuesday, April 11, 2017 at 12:39:09 PM UTC-7, Michael Graves wrote: