New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on: View detail
issue 7494
issue 10232



Sign in to add a comment
link

Issue 8434: Excessive AEC suppression

Reported by jv...@twilio.com, Oct 23 2017

Issue description

I am creating a new ticket, but this maybe the duplicate of https://bugs.chromium.org/p/webrtc/issues/detail?id=5201, so please feel free to close it.

I have included free files at https://drive.google.com/open?id=0B80gVLdGLx4XZGpnNWMyTmt1RkU:
1. Source input - 24 minutes long, please start listening at 23:00.
2. aecdump - Each file is 24 minutes long, please start listening at 23:00.
3. Audio recorded at Twilio - 1 minute long

Audio going out to the wire is not understandable. You can validate that audio going out to wire is the same as recorded by Twilio.
 

Comment 1 by rom...@aircall.io, Oct 24 2017

Hi,
It is one of our sales rep that experienced the issue. They do experience the issue quite a lot but it is quite a complicated process to get the log files.
They are based on MacOS with a Jabra Evolve 40 through mini-jack. However some of our customers escalated the issue with different setups (Windows, USB headset, etc).
Thanks a lot for your help!

Comment 2 by phoglund@webrtc.org, Oct 26 2017

Project Member
Components: Audio

Comment 3 by henrik.lundin@webrtc.org, Oct 30 2017

Project Member
Cc: gustaf@webrtc.org
Owner: p...@webrtc.org
Status: Assigned (was: Unconfirmed)

Comment 4 by gabr...@aircall.io, Sep 3

Hi, 

Our clients are still experiencing an issue where audio input suddenly fades in and out,  and during these phases the audio sounds very muffled (just like it went through a Low Pass Filter) or even disappears. 

I’ve attached a google sheet with 8 recent examples with recordings, from several clients using various configurations (more info below).

The issue seems to be linked with the excessive AEC suppression, for which I found some information here: 
https://bugs.chromium.org/p/webrtc/issues/detail?id=5201
https://bugs.chromium.org/p/webrtc/issues/detail?id=4292
https://groups.google.com/forum/#!topic/discuss-webrtc/fgJEv_Ziy_g

We have the following questions: 
- Do you think the examples provided relate to echo cancellation (cf. tickets / discussions above)?
- Is there any workaround that we should test (from our past experiences disabling echo cancellation create more issues than it solved)?
- Is AEC3 a solution to this issue? 
- Is there a particular audioconstraints configuration you would recommend to avoid this particular issue? 
- What about the native echo canceller? 
- Is this trackable?

This is a critical issue for our 3000 customers, so your feedbacks would be greatly appreciated.

Thanks in advance, 
Gabriel Guedj

Our clients can use either: 
an Electron App with Chrome 61 -> Twilio -> PSTN 
an Electron App in beta with Chrome 66 -> Twilio -> PSTN
a Web App with Chrome (version depends on the user) -> Twilio -> PSTN

And we use the default following WebRTC audio constraints.

Here is the full list of examples with recordings: https://docs.google.com/spreadsheets/d/1pwTHgbSIPfRpi79qeZU3ggjwz5nVER1G-_d5pcZlOss/edit?usp=sharing

Comment 5 by p...@webrtc.org, Sep 3

Project Member
Hi,
Thanks for the update!
From the audio samples, it sounds like it could be AEC-related but without aecdump diagnostic recordings it is very hard to tell.

The issue of less than ideal transparency is known (one of the bugs for that is in the list you provided). The AEC3 and the native echo canceller are the approaches we are working on to address that so the expectation is that those issues should be improved by those. 
For AEC3, it is recommended to use a version >= M69 for that to fully work without known issues.

Would it be possible for you to make an aecdump recording of a call when the issue is present? That would provide us with information that clearly shows what the issue is and allows us to take the proper action to solve the issue.
(the aecdump recording can be from any of the Chrome versions mentioned in #5).

Comment 6 by gabr...@aircall.io, Sep 4

Hi, 

Thanks for answer. It's pretty hard to get the dumps from our clients. Nevertheless we've been able to reproduce the issue internally. I put a link to the wav files and the aec dumps (more details below). 

These are the steps to reproduce the issue: 
- 1 agent (agent 1) is in a room and calls another agent (agent 2) in another room
- Agent 1 doesn't have a headset/micro & agent 2 has one
- Agent 2 reads a text
- At some point agent 1 plays an audio file of people speaking noise (we actually took this video https://www.youtube.com/watch?v=WDqbXzIagPc) then stops the file then plays it again
- We find a fade in / fade out at the exact moment Agent 1 plays the audio file: he cannot hear Agent 2 for a short while and then it comes back to normal 

You'll find the audio outputs of the Agent 1 and the AEC dumps here: https://drive.google.com/open?id=1wHRzkknefGj5tiuenzJPs5K7xDJk2HUH

- First call: 

Audio output: audio_debug2.output.147.wav
AEC dump: audio_debug2.*.aec_dump files (4 files, not sure which file was the right one)
Issue is found from 0:47 to 0:49
and from 1:14 to 1:17

- Second call: 

Audio output: audio_debug3.output.153.wav
AEC dump: audio_debug3.*.aec_dump files (2 files, not sure which file was the right one)
Issue is found from 0:42 to 0:47
and from 1:00 to 1:07

Do you confirm it's AEC related? 

Thanks in advance,
Gabriel Guedj

Comment 7 by gabr...@aircall.io, Sep 10

Hi everyone, 

A little update on our side; we've done extensive tests and finally came up with a workaround (for now only on mac OS), which is basically enabling the native echo canceller. 

You'll find here a recording of the classic Chrome echo canceller (starts at 00:23): https://drive.google.com/open?id=14910VTRs7am5tfC35AV2iD72Sd9XiqF9

and here's a recording in the same setup of the native echo canceller (start at 00:19): 
https://drive.google.com/open?id=1fv0F4Mj9EyZtExqvtS5NQAjjSy7F8cnw

As you can hear in the later you can hear crackling noises but you can at least hear the speaker, which you cannot in the first recording. 

Hope this will help other people who would run into the same issues than us. 

Thanks, 

Gabriel

Comment 8 by peah@chromium.org, Sep 23

Thanks for the recordings!

Regarding comment# 7: I'm glad you found a working workaround! Listening to these recordings I would definitely agree on the AEC choice as the transparency of the native AEC is much better (albeit it has some noises).

Comment 9 by p...@webrtc.org, Sep 23

Project Member
Regarding comment# 6: The recordings were great, and show what the issue is. The issue is AEC related and the underlying cause is that the echo is heavily saturated in the microphone signal. This causes quite strong ducking in the echo canceller as it needs to take headroom due to the nonlinear echo effect caused by the saturation. 

The solution for this is to adjust the WebRTC analog AGC behavior to ensure that the echo is not saturated. Then the AEC performance would be more matching the native AEC which has its own control of the analog microphone gain.

There is ongoing work for that, but in the meantime the shift to using AEC3 instead of AEC2 should improve the transparency in these cases (at least it does on these recordings).

We will try to further improve the performance during saturated echoes, but due to that the nonlinear effects of the clipping of the echo are not modelled by the WebRTC AEC, it is very hard to achieve significant further improvements on the transparency without risking echo leakage.

Comment 10 by p...@webrtc.org, Sep 23

Project Member
Cc: ale...@webrtc.org p...@webrtc.org
alessiob@: The main cause for the poor AEC transparency in this scenario is that the analog AGC allows the echo to saturate.

Is there a bug for this on the analog AGC which we can block this issue on?

Comment 11 by aleloi@chromium.org, Sep 25

Re comment #10: we have the bug webrtc:7494 that tracks all AGC-related work.

Comment 12 by p...@webrtc.org, Sep 25

Project Member
Blockedon: 7494

Comment 13 by ossu@webrtc.org, Dec 20

Project Member
Cc: ossu@webrtc.org
Hello again.

I've listened to the recordings in #6 and #7 and see the problem. Unfortunately, the aecdumps in #6 seem to be done from the perspective of agent 1, whereas the problem is actually caused on agent 2's side.

Is it possible to do an aecdump from your side when this happens, either by reproducing like in comment #6, or by having someone call in from an environment where you usually get these problems. Please do this on Chrome M71 and using AEC3 (locally). This information will help us evaluate how things are going wrong.

Could you also tell us about the audio setup, e.g. what headset is being used, as that may be a factor?

Comment 14 Deleted

Comment 15 Deleted

Comment 16 by alessand...@gmail.com, Dec 20

Hello
We'll send you the dump ASAP, regarding the setup we noticed that on mac os the best solution is to plug the headset via jack and in the windows case via USB.

Let me know if and how we can help and thanks for your work.

Comment 17 by alessand...@gmail.com, Dec 31

Hi, I'm experimenting AEC3 but we are noticing that there are some windows laptop where is impossible to set the preferred `echoCancellerType` as if the option was disabled: even in `getCapabilities` the parameter is not present. 

Any suggestion? Thanks for your help.

Comment 18 by alessand...@gmail.com, Jan 2

Hello again, 
here a dump on a receiver side with the aec3 activated on the sender.
In the `reverse.wav` you can hear the issue. 

https://bayfiles.com/B8K00dpdb3/audio_debug_damien.66538.aec_dump_7

Comment 19 by alessand...@gmail.com, Jan 2

I think that this information can help: to reproduce the issue we had to use a MacBook Air because with a MacBook Pro is more difficult and rare.
Do you think that is because the CPU is powerful and then the AEC3 algorithm can run better or because the audio HW is different?

Comment 20 by dam...@aircall.io, Jan 2

Hello,

And here is a dump on the emitter side.
You can notice the issue between 0:40 and 1:00 in ref_out3092.wav.
And as you can see there is no issue in input3092.wav.

https://bayfiles.com/QaR506p4bc/audio_debug.1215.aec_dump_7

Comment 21 by alessand...@gmail.com, Jan 7

Hello guys! 
I know I can seem a little bit pushy but I have to ask you: any news? :)

Comment 22 by p...@webrtc.org, Jan 7

Project Member
Thanks for the AECdumps! I have not yet looked at them though.

Would it be possible to upload them on some other cloud storage instead? google drive would be prefferred (as was done in #7).

Comment 23 by alessand...@gmail.com, Jan 7

We have a file size problem if I remember correctly the gdrive limit is 100MB

Comment 24 by henrik.lundin@webrtc.org, Jan 7

Project Member
Re #23: Are you sure? This support answer suggest "All other files: Up to 5 TB": https://support.google.com/drive/answer/37603?hl=en.

Comment 26 by henrika@webrtc.org, Jan 10

Project Member
Cc: henrika@webrtc.org

Comment 27 by p...@webrtc.org, Jan 10

Project Member
Thanks for the recordings!
Looking at the audio in the recordings in #18 and #19 the issue I see is ducking/aec suppression which is something we constantly strive to improve. 

Some observations are
-The ducking in these recordings are not that bad, considering that the echo is in some frequency regions quite much stronger than the speech, and the far-end is playing constant music.
-I'm not that sure the recordings really show the problems you are describing (herein and offline). The reason for that is that the other endpoint actually has more ducking than the one using AEC3 (the other endpoint had AEC2), which means that the constant doubletalk is not as constant as it could have been.
-AEC3 performs better on this recording than AEC2.

I definitely agree that it would be desired to improve the performance in these cases, but based on these recordings I'd say that the performance is on par with what is expected and the performance in the recordings is has a high level of duplex.

I definitely think that the transparency of the native Mac OS AEC would be better on these recordings but we still cannot recommend using that as we have found it inferior in our testing. 

(I also analyzed the recordings sent offline to alessiob@ and will comment on those in another comment below)

Comment 28 by p...@webrtc.org, Jan 10

Project Member
Regarding the other recordings sent, the conclusion is close to the same. The issue of transparency is more apparent in those but still I would say it is ok in this conversation, primarily due to that there is not that much doubletalk and as that the echo level is quite strong.

As said above, this is something that is being worked on to improve in general but I cannot see anything in these recordings that indicate that something goes wrong in the processing. Furthermore, AEC3 is more transparent than AEC2 on these recordings.

Note that probably it is fairly easy to tweak/re-tune the processing to work well on these recordings but the AEC need to handle all other scenarios as well.

Comment 29 by alessand...@gmail.com, Jan 10

Hi there,
thanks for the response. 
I agree that we stress a lot the AEC in our test but we do that because is the faster way that we found to reproduce our customer issue (their interlocutors are often on a mobile device we don't know if and what type of echo canceller they are using).

The only thing that I can say is that since you removed the native echo canceller support on Windows our customer restart to facing the 'muffled voice' issue.

If we find a way to use always AEC3 (on M72 beta seem to be more efficient) for us will be fantastic because is true that today we use the native one and it works but it's also true that we count on the customer's HW and, in some cases, we noticed a long `getUserMedia`computational time.

Question:
Today we forced the `echoCanceller` to AEC3 because when we use the "Experimental support for native AEC" the option 'echoCancellationType' is enabled and we can set it, is there a way to do it without the experimental token?

Comment 30 by alessand...@gmail.com, Jan 10

Another thing that we don't understand very well but it seems to be a pattern is:
why we have this issue mostly in the scenarios in which the user is on a not really powerful laptop? Is something related to the CPU or memory?

Comment 31 by p...@webrtc.org, Jan 10

Project Member
Thanks!
The feedback on issue the muffled audio is great for us and I definitely believe that the issue is there and is experienced by your customers. But I don't think that the issue is so severe in the recent recordings that it would cause customer complaints. That may either be  because the cause for the issue did not occur, or because the recordings did not replicate the scenarios where it happens.


There are two things that I suspect potentially could differ between the devices you describe and that we have seen could cause issues of muffled audio are 
1) Consistently saturated echo (I commented on that in #10).  
2) Issues with varying latency in the audio buffers caused by highly loaded CPUs.

I've looked for both in the recordings you provided but neither of those occurred there. That does, however, not mean  that they don't occur in the other calls.


If you are able to, it would be really good if you could make some more recordings on the devices you think are more problematic. And to make the analysis more clear, it would be great if you can make the recordings as below:

1. Set up a call between two endpoints A and B where A is the device you want to test and B is a device you find good in general. If possible, it would be good if a good headset is used at B. A should be used in the way you usually use it when you get complaints.
2. Start the call.
3. Let the person at A speak for about 5 seconds (constant speech, just to ensure that the AEC at B is properly converged). During this time, the person at B should be silent.
4. Then let the person at B speak constantly (lots of speech) for up to 5 minutes (longer recordings are hard to analyze). During this time, the person at A should be silent.

The above will not show the muffledness but will potentially allow pinpointing the root cause for the muffledness.


I'm aware that making recordings take a lot of time, but to take the proper action a recording of the issue is needed. So if you are able to send us some more recordings made on these devices it would be great!

Comment 32 by alessand...@gmail.com, Jan 10

Thank you for the exhaustive response, really clear.

We'll send you the recording as soon as possible.

Comment 33 by henrikg@webrtc.org, Jan 11

Project Member
Cc: henrikg@webrtc.org

Comment 34 by gabr...@aircall.io, Jan 15

Hi all, 
As promised we made the requested recordings using your method. We did 6 tests, with various configurations — we used 3 different laptops for person at A, and tried each time USB vs Mini-Jack ; person at B has always the same configuration. 
Each tests are made on M71 on both ends. 
You'll find all sorted AEC Dumps here: https://drive.google.com/open?id=16dmy0zU_-x5AIv8TdcJT5gbLFvPMrMec

- Test 1
A 
HW: ASUS ZENBOOK FLIP UX360CA C4004R - 13.3" - CORE M3 6Y30 2.2GHz - 8 GO RAM
OS: Windows 10
Headset: Jabra Evolve 40 (plugged with USB dongle)
B
HW: MB Pro early 2015 Retina 13" - Intel Core i5 2.7GHz - 8 GO RAM
OS: MacOS Mojave 10.14.1
Headset: Jabra Evolve 40 (plugged with mini-jack)

- Test 2
A 
HW: ASUS ZENBOOK FLIP UX360CA C4004R - 13.3" - CORE M3 6Y30 2.2GHz - 8 GO RAM
OS: Windows 10
Headset: Jabra Evolve 40 (plugged with mini-jack)
B
HW: MB Pro early 2015 Retina 13" - Intel Core i5 2.7GHz - 8 GO RAM 
OS: MacOS Mojave 10.14.1
Headset: Jabra Evolve 40 (plugged with mini-jack)

- Test 3
A 
HW: Acer Swift 3 SF314-52-70QS - 14" -  Intel Core i7-7500U (2,7 GHz)  - 8 GO RAM
OS: Windows 10
Headset: Jabra Evolve 40 (plugged with USB dongle)
B
HW: MB Pro early 2015 Retina 13" - Intel Core i5 2.7GHz - 8 GO RAM
OS: MacOS Mojave 10.14.1
Headset: Jabra Evolve 40 (plugged with mini-jack)

- Test 4
A 
HW: Acer Swift 3 SF314-52-70QS - 14" -  Intel Core i7-7500U (2,7 GHz)  - 8 GO RAM
OS: Windows 10
Headset: Jabra Evolve 40 (plugged with mini-jack)
B
HW: MB Pro early 2015 Retina 13" - Intel Core i5 2.7GHz - 8 GO RAM
OS: MacOS Mojave 10.14.1
Headset: Jabra Evolve 40 (plugged with mini-jack)

- Test 5
A 
HW: MB Air early 2015 Retina 13" - Intel Core i5 1.6GHz - 4 GO RAM - 
OS: MacOS Mojave 10.14.1
Headset: Jabra Evolve 40 (plugged with USB dongle)
B
HW: MB Pro early 2015 Retina 13" - Intel Core i5 2.7GHz - 8 GO RAM - 
OS: MacOS Mojave 10.14.1
Headset: Jabra Evolve 40 (plugged with mini-jack)

- Test 6
A 
HW: MB Air early 2015 Retina 13" - Intel Core i5 1.6GHz - 4 GO RAM 
OS: MacOS Mojave 10.14.1
Headset: Jabra Evolve 40 (plugged with mini-jack)
B
HW: MB Pro early 2015 Retina 13" - Intel Core i5 2.7GHz - 8 GO RAM 
OS: MacOS Mojave 10.14.1
Headset: Jabra Evolve 40 (plugged with mini-jack)

Hope it helps,
Thanks!

Comment 35 by p...@webrtc.org, Jan 15

Project Member
Awesome! Thanks!

The link only is for one of the recordings though, and I seem not to be able to access the other recordings.

Could you please add the link to access the other recordings?

Comment 37 by p...@webrtc.org, Jan 18

Project Member
Status: Started (was: Assigned)
Thanks again or the thorough recordings!

I could not find any evidence for neither of the potential causes for muffledness  i mentioned in #32. 

I did, however, make some observations:
-The person at B in all the recordings have strong echo in the mic which is a bit surprising considering that a headset is used. 
-In test 2, the device used in A (ASUS ZENBOOK FLIP UX360CA C4004R) has a HW AEC which leaks echoes. The leakage is not so much that the cascade operation with the WebRTC SW AEC can identify it though but it sounds bad.
-The linearity in the recordings where there is clear echo is really good and the linear filter does a good job in removing the echoes.


As I don't see any causes for muffledness in these recordings, more recordings are needed to pinpoint the causes. What we then need is similar recordings but where the person at A in step 4) (in comment 31) speaks some words. A suggestion is that that person should count. (please do that counting in english to simplify the analysis). The idea is that one should try to catch instances where that person is muffled.

Apart from that my guess is that there are issues when the Jabra is connected via the mini-jack as the echo is very strong in general for all endpoints B, regardless of a headset being used. (Furthermore, the quality of the Zenbook audio used in this test is not good due to the leaking HW AEC).

Comment 38 by gabr...@aircall.io, Jan 18

Thanks for your detailed answer!

We'll do the requested tests early next week. Could the strong echo of the Jabra headset plugged in mini-jack be a possible cause for muffled audio? 

This could explain why we are affected more than others by the muffledness issue, as we actually recommend our Mac OS users this headset, plugged in mini-jack... And a lot of them follow our recommendations. 

Thanks!

Comment 39 by p...@webrtc.org, Jan 21

Project Member
I'm not sure. The AEC performed quite well on those so the audio should not be muffled. But let's see what the recordings show.

Comment 40 by gabr...@aircall.io, Jan 22

Hi, 

We did the test in the Test 1 configuration described in #34 with person at A counting first, and then B starting counting at a different pace. I think we can hear the muffledness issue from 00:23 to 00:29 (the voice of the person at A is muffled, this time pretty heavily i believe). You can find the dumps here: 
https://drive.google.com/drive/folders/1ox8pmu3Pqfe39krzwDrcnygNR0iq0zfC?usp=sharing

Do not hesitate if you need more tests from us in other configurations. 

Thanks!

Comment 41 by p...@webrtc.org, Jan 22

Project Member
Blockedon: 10232

Comment 42 by p...@webrtc.org, Jan 22

Project Member
Thanks again for the recordings!!! 

-testA.4900.aec_dump.7:
The AEC3 performance is perfect apart from 10-14 seconds where the transparency is really poor.

-testA.4900.aec_dump.5:
The AEC3 performance is perfect apart from 12-20 seconds where the transparency is really poor.

-testB.2597.aec_dump.13
Transparency is poor throughout the recording. The culprit is the Jabra which causes the input to the AEC to have poor transparency. The Jabra also leaks distorted echoes.

-testB.2597.aec_dump.8
Transparency is better than the one above, and quite good considering that the Jabra in this case leaks distorted echoes.


I'm not sure that we've pinpointed the problem with muffledness but the behavior between 10-14 and 12-20 seconds sounds like it could be that. I don't hear the muffledness between 23 and 29 seconds though. That was in the recordings from A, right? Which one of them?

The conclusions I can make from the recordings are
1) There is an issue with low transparency in the recordings from A at the initial onset of the render signal. The issue is known, and is partly a deliberate tradeoff to avoid echo leakage before the AEC models are trained. I have not before seen it as extensive as in here before though. I created a separate issue for that (https://bugs.chromium.org/p/webrtc/issues/detail?id=10232).

2) Apart from 1) from what I can see the transparency in the recordings from A is really good, in particular considering that that endpoint has lots of noise in the background.

3) The transparency of the endpoint at B is quite poor, but there the culprit is the Jabra which has a poor transparency. It also leaks echo.

Comment 43 by p...@webrtc.org, Jan 22

Project Member
Thanks again for the recordings!!! 

-testA.4900.aec_dump.7:
The AEC3 performance is perfect apart from 10-14 seconds where the transparency is really poor.

-testA.4900.aec_dump.5:
The AEC3 performance is perfect apart from 12-20 seconds where the transparency is really poor.

-testB.2597.aec_dump.13
Transparency is poor throughout the recording. The culprit is the Jabra which causes the input to the AEC to have poor transparency. The Jabra also leaks distorted echoes.

-testB.2597.aec_dump.8
Transparency is better than the one above, and quite good considering that the Jabra in this case leaks distorted echoes.


I'm not sure that we've pinpointed the problem with muffledness but the behavior between 10-14 and 12-20 seconds sounds like it could be that. I don't hear the muffledness between 23 and 29 seconds though. That was in the recordings from A, right? Which one of them?

The conclusions I can make from the recordings are
1) There is an issue with low transparency in the recordings from A at the initial onset of the render signal. The issue is known, and is partly a deliberate tradeoff to avoid echo leakage before the AEC models are trained. I have not before seen it as extensive as in here before though. I created a separate issue for that (https://bugs.chromium.org/p/webrtc/issues/detail?id=10232).

2) Apart from 1) from what I can see the transparency in the recordings from A is really good, in particular considering that that endpoint has lots of noise in the background.

3) The transparency of the endpoint at B is quite poor, but there the culprit is the Jabra which has a poor transparency. It also leaks echo.

Comment 44 by p...@webrtc.org, Jan 22

Project Member
To summarize the above:
-I don't think the recordings pinpointed the muffledness issue we are looking for.
-The recordings pinpointed an important issue during call startup.

Please feel free to send more recordings of when the issue occurs!

Comment 45 by alessand...@gmail.com, Jan 23

Hi, 
can it help if we send you .wav recording?

Comment 46 by p...@webrtc.org, Jan 23

Project Member
Yes, that would be great! Please do that.

Comment 47 by gabr...@aircall.io, Jan 23

Thanks! 

I added in the drive the recordings on which I thought I perceived the issue: the recordings of the input of person at A and the output of person at B. I trimmed them so they start at the same timestamp (I realized the timerange I pinpointed in #40 is confusing because of that).


You can hear in the first one that from 00:08 to 00:14 the person at A is counting from 1 to 10, though in the second one you start hearing him counting only at 4 (at 00:11). Is that the 1) poor transparency issue  you pinpointed in #43?

Regarding the poor transparency of the Jabra: am I correct in my understanding when I say that because of the stronger echo in the Jabra, the AEC at B reacts accordingly and suppresses audio more than average on the input, causing poor transparency overall?

Thanks!

Comment 48 by p...@webrtc.org, Jan 23

Project Member
Yes, that is what I meant of by the poor transparency issue.

But since I know why and where it occurs I'm not that sure that this fully maps to the muffled audio issue you have. Mainly as it only should occur at call startup and in general not be as bad as this case.


Regarding the Jabra, the WebRTC AEC actually does a good job, and does only little, or not at all, affect the transparency. 
Instead it is the Jabra AEC that has the issues
1. Has a low transparency.
2. Partly leaks echoes.

Why the Jabra AEC has that behavior, I cannot tell.

Comment 49 by gabr...@aircall.io, Jan 23

That's strange though, as the same model is used by the person at A (in USB) - that could mean that it is this particular piece of headset that is faulty? Or maybe it uses the AEC in the USB dongle at A?

Comment 50 by p...@webrtc.org, Jan 24

Project Member
I agree, that is strange.

Comment 51 by ossu@webrtc.org, Jan 24

Project Member
Are we sure the Jabra has an integrated AEC? I tried looking up the model on their site and it doesn't mention anything about that. There does seem to be a Jabra application, though, that can be used to configure a number of features, including sidetone. Perhaps there's more info in that app.

Comment 52 by p...@webrtc.org, Jan 24

Project Member
I cannot be fully sure but what I base that comment on is.

I attach a spectrogram for the mic input of testB.2597.aec_dump.13
There are lot's of gaps in it corresponding to full silence in the capture input. 
That in turn cannot be achieved without some kind of processing.

Furthermore, the audio sounds processed.
Screenshot2019-01-2411:21:12.png
2.0 MB View Download

Comment 53 by gabr...@aircall.io, Jan 24

I'm pretty sure MacOS adds audio processing when plugged in mini-jack. 
That might be it: I had the "Use ambient noise reduction" box checked when I did the recording. 

I added in the drive two recordings of me in the same setup (MacBook Pro + Jabra Headset mini-jack) counting from 1 to 10 with the box checked and without it, maybe it can help you assess if the processing you noticed come from the Mac? 

Note that the box does not exist when using an USB input.

Comment 54 by p...@webrtc.org, Jan 24

Project Member
Good point! That could be the reason.

Comment 55 Deleted

Comment 56 by alessand...@gmail.com, Jan 28

Hello again, sorry I added this question at #29 but I think that it is not been noticed:

Today we forced the `echoCanceller` to AEC3 because when we use the "Experimental support for native AEC" the option 'echoCancellationType' is enabled and we can set it, is there a way to do it without the experimental token? 

In other words: How we can be sure that we are using AEC3?

Thanks.

Comment 57 by p...@webrtc.org, Jan 28

Project Member
If you don't set the echoCancellationType explicitly, or use the chrome command line to turn off AEC3, you will now use AEC3 as it is fully launched in M71.

Comment 58 by alessand...@gmail.com, Jan 28

Perfect thank you!

Sign in to add a comment