Sounds like it could be an issue with the audio processing module in WebRTC. To help figuring out what the issue is, could you go to chrome://webrtc-internals and under "Create Dump" check "Enable disagnostic audio recordings" and "Enable diagnostic packet and event recording"? Then upload the resulting files here. Data from both participants of the call is ideal.

Hi,

since max attachment size is 10MB and I have about 80MB of files, here is the link: https://1drv.ms/f/s!AvQzf8Ww2XwMheMaKcXlkIb0B4P1TA 

For immediate comparison, listen to mp3 files "WithCrossTalk_AUDIENCE" and "NoCrossTalk_AUDIENCE".

Set-up is the following:

To clearly analyze the influence of the cross talk, I have set up two conferecne calls.

3 Laptops: Speaker 1, Speaker 2 and Audience.

Speaker 2 has two simultaneous conference calls from the browser: with Speaker 1 and with Audience. Speaker 1 is on call with Speaker 2 only, to simulate cross talk. Audience is on call with Speaker 2 only, Audience has microphone turned off (listen-only).

Attached files are for Speaker 2 and Audience only. Speaker 1 is just used to simulate crosstalk, his files are not relevant.

NoCrossTalk files: 
Speaker 2 speaks to Audience. Audio quality that audience receives is good.

WithCrossTalk files:
Speaker 2 speaks to Audience, but a the same time Speaker 2 receives voice from speaker 1. Audio quality that audience receives is terrible.

For comparison, I also enclosed Firefox....mp3 file for the audience, same set up with cross talk. Quality is much better than Chrome.

My guess is that AEC thinks that Speaker 1 voice is an echo and tries to adjust Speaker 2 voice. 
Supposed behaviour: AEC should ignore sound of other speakers in the call.

Thank you for providing more feedback. Adding requester "maxmorin@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Just in ase, added audience mp3 files here. The rest is too large and can be found under the link in the comment above.

Deleted: NoCrossTalk_AUDIENCE-received.mp3 453 KB

NoCrossTalk_AUDIENCE-received.mp3 453 KB Download

Deleted: WithCrossTalk_AUDIENCE-received.mp3 455 KB

WithCrossTalk_AUDIENCE-received.mp3 455 KB Download

There doesn't actually appear to any echo in the microphone signal before processing, so I guess this might be an issue with using multiple echo cancelers. Per: Could you have a look? If it's not too much work, could you check if AEC3 does a better job with WithCrossTalk_SPEAKER-sending.4740.aec_dump.1?

(actually, I think the output just isn't played out, thus there is no echo in the input signal).

I remember that when I looked at AEC chart in WebRTC-internals, I saw that it kicks in when other speaker is talking. I guess this shouldn't be the case? 

"Could you have a look? If it's not too much work, could you check if AEC3 does a better job with WithCrossTalk_SPEAKER-sending.4740.aec_dump.1?"

What exactly do I need to do to check this? 

Sorry, that was directed to Per, who is working on a shiny new AEC. I'm not sure about the status of AEC3 in Chrome, maybe there's a flag for it.

Hi,
First of all, the two cases you are comparing are very different: the no-crosstalk case does not include any render signal, while the other does, so it is not a relevant comparison.

The behavior that you describe we call "ducking" and there is a webrtc issue for that. You are using a headset, right? 

The issue with having "ducking", even though there is no echoes, is know, have been there for a while (longer than M55) and is being worked upon within the scope of AEC3 which should eventually handle this case better.

I'm a bit surprised that you see a difference between M55 and M56 as there "should" be no changes in the code that causes this to change. Could you please be more specific in the way the behavior differs? It would also be great with an aecdump recording from M55 where this behavior is not present. 

andsh394@: Please get back with aecdump recordings from M55 that illustrates the regression between M55 and M56.

By "render signal" you mean Speaker 1?

Could you please help me with finding a download link for M55 for Win64? Then I can test again on the old browser. I looked here https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/ , but get confused with version numbers.
Thanks!

peah@ 

Here are the files for Chrome 53 and 55, to compare:
https://1drv.ms/f/s!AvQzf8Ww2XwMheM5hDDPBq8hXzOqJA

I find quality is better than with 56 and 57.

And here are audience audio files uploaded directly, for convenience. For AEC dumps follow the link above.

Deleted: v53_AUD.mp3 1.0 MB

v53_AUD.mp3 1.0 MB Download

Deleted: v55_AUD.mp3 1006 KB

v55_AUD.mp3 1006 KB Download

Thanks for the recordings!

By "render signal" I mean the signal that is going out for playout. 
I don't see that being present in the 
Test4log.4156.aec_dump.3
Test5log.4284.aec_dump.1
NoCrossTalk_SPEAKER-sending.10376.aec_dump.1
files provided in the links above

It is, however, present in the file
WithCrossTalk_SPEAKER-sending.4740.aec_dump.1


The AEC behavior depends a lot on whether render signal is being passed to the AEC or not. If no render signal is present, the AEC assumes that there is no audio being played out and hence can safely assume that can be no echo. If, on the other hand, the render signal is present, the AEC needs to detect whether an echo is present in the microphone signal or not. Due to this, it is not a relevant comparison to compare recordings where no render signal is present and when it is not.

I'm not sure what you are doing in the recordings 
Test4log.4156.aec_dump.3
Test5log.4284.aec_dump.1
NoCrossTalk_SPEAKER-sending.10376.aec_dump.1
but my guess is that that setup for some reason is different from the one in WithCrossTalk_SPEAKER-sending.4740.aec_dump.1.

As it is now only the WithCrossTalk_SPEAKER-sending.4740.aec_dump.1. recording can be used to evaluate the AEC (as that is the only one where the AEC can be, and is active. For that recording, I hear no echo at all in the microphone signal. Are you using a headset for the playout, or is the playout muted? There is a known issue for the AEC performance for such cases where the AEC suppresses too much and that is something that AEC3 should handle better.

I cannot tell whether there is a regression in the AEC performance since Chrome 53 and 55, as the recordings are different (those recordings contain no render signal which causes the AEC to never be activated). I would need recordings where there is a render signal to really tell whether there has been a regression.

Would it be possible for you to create new recordings from Chrome 53/55 where there is a render signal. Also, it would be good to have it confirmed whether you are using a headset for the tests.

From #4 it sounds like this may be a duplicate of https://bugs.chromium.org/p/chromium/issues/detail?id=695993

Alex, could you advise on a Chrome version that includes your fix so that they could try that out?

Why do you think that? When listening to the files this sound like clear "ducking" caused by the AEC.

Or do you mean that the lack of a render signal could be caused by the above issue?

peah@ 
Cannot judge why render signal is not there: 
set-ups for Test 4, Test 5 and WithCrossTalk were the same. The difference is that those set-ups used Chrome 53, 55 and 57, respectively. So only Chrome 57 generated render signal.

NoCrossTalk does not have render signal, because we only had one speaker, Speaker 2.

So just an idea: may be AEC has nothing to do with it, and Chrome 57 handles "two sessions" set up differently?

The set up for  files above was following:
Speaker 1 speaks to Speaker 2. They are on different laptops, in different countries. Speaker 2 has two calls set-up: one to listen to Speaker 1, and another one, in the same browser tab, to talk to the Audience.

AEC files I sent are from Speaker 2.

So my understanding is that on Chrome 53 and 55 Speaker 1 (incoming sound) is not being treated as render signal, since Speaker 2 is talking in a different session. This should be correct behaviour.
However, on Chrome 57 ("WithCrossTalk" file) you can see render signal and this means Chrome decides that incoming sound on another "call" is a signal that must be processed by AEC, hence the issues.
Can this be correct? 

Note: we used headsets for all set-ups.

#20: Sorry, I was jumping to conclusions from the problem description and Chrome revision range. You're right - this clearly sounds like ducking.

Decided to add few sound files to show that the sound quality is poor on Chrome even with AEC off, in our situation.

https://1drv.ms/f/s!AvQzf8Ww2XwMheNY5JyHJlCZKjBygA

Audience sound was recorded with Audacity, for the set-up described above (i.e. Speaker is also simultaneously receiving audio on another WebRTC call, which disturbs the sound).

I added 3 files in the folder: 
1) AEC is off (googEchoCancellation=false) on speaker's browser
2) All audio processing is off (echoCancellation=false) on speaker's browser
3) Same set-up, but speaker and audience are using Firefox.

In 3 we have much better sound. Chrome is struggling to provide good audio even with audio processing turned off (though it does help).
So for our set-up, AEC and AGC ON provide worst quality, turning them off makes things better, but sound still does not reach level of Firefox.

What, in addition to AEC, can be improved on Chrome to handle our case better?

What's the status of this and next step? Should peah@ be the owner?

Yes, I probably should be the owner.

Regarding #23: 
I've listened to the recordings and I might possibly agree that the Firefox recording is slightly better. I don't think the difference is huge, however, and it is quite hard to tell as the recorded scenarios differ. Furthermore, the microphone signals are somewhat saturated.

Could you point out some specific region in the recordings where there is an issue. You say in #1 that " his voice gets severely distorted." Do you have any place example of where that happens?

Regarding AEC, from the recordings I've seen in this issue, I think there is only one where the AEC could have been active (as in the other recordings the AEC did not see any render signal and therefore was not in an active state), and that was affected by the ducking issue when using headsets which is being addressed in current AEC work.

The difference might be acceptable for a simple video call, though I do not think it is

Unfortunately we are in B2B and our clients do complain about the quality. If you use Hi-Fi USB Mic and headset, and stream at higher bitrates, drop in quality is even more noticeable. If Chrome could do it before, and Firefox can do it, then it can be improved?

For example of a place where you have drop in quality, you can listen to any place, for example first 10s for WithCrossTalkAudience and NoCrossTalkAudience that I attached before in my second post (attached here again now).

This got slightly better in Chrome 58, but still noticeable.

Deleted: NoCrossTalk_AUDIENCE-received.mp3 453 KB

NoCrossTalk_AUDIENCE-received.mp3 453 KB Download

Deleted: WithCrossTalk_AUDIENCE-received.mp3 455 KB

WithCrossTalk_AUDIENCE-received.mp3 455 KB Download

I do think that AEC might not be the only issue here, since we do have lower quality in Chromium than on Firefox. 
Just for you to have a complete picture, we do have different audio bitrates set for Speaker 1 and Speaker 2. Do not think this should be a problem though

*....lower quality in Chrome than Firefox even with AEC, AGC and NR off.

Thanks for the additional information. My concern is that I may be missing what the real issue is and that there is something else that causes the degradations and complaints from your clients.

Let's try to pinpoint exactly what the issue is. As there are quite many aspects of this issue, I'll split the aspects into separate bullets:
1) I've listened to, and analyzed the characteristics of the two files in #28 and the WithCrossTalk recording is a bit worse, but I wouldn't expect non-expert users to complain about that. Therefore, I don't think that it really captures the issues that the complaints are on. If possibly, could you please point to a place (with exact time information) in the recording where you think there is a problem, and describe how you think it should be.

2) In the recordings in #4: the recordings with crosstalk have aa render signal and the one with no crosstalk don't. 
As I've explained about, the presence of the render is crucial for the AEC behavior, and if you compare the performance between it being present or not, that will definitely cause different behaviors. The AEC is not at all active if the render signal is not present. 
Therefore, what you basically are describing as the issue when comparing the signals in #28 is that the quality is better when the AEC is on than when it is off. That we are working on improving and if the issues addressed herein are only due to that, I think we should link this issue to that work.
When listening to the signals I again think the signals with crosstalk (and with the aec being on) are somewhat worse but not more than that I would not expect user complaints.

3) Regarding the statement that Firefox don't have this behavior, and Chrome does could you please clarify that? The example of this is the .mp3 files in #4, right? I don't hear a clear difference there either, could you please pinpoint a specific place where you perceive a difference?

4) Regarding the Chrome versions, #1 indicates that there is a regression in M56/M57 compared to M55. Is that correctly interpreted?

5) The recordings in #15 are very interesting, I probably did not listen previously to the recording for M55 as #1 stated was that there was a regression in M56/M57. Something is actually very wrong in the input signal for M55. This is also clearly audible in the .mp3 files. Note, however, that
  -This is present in the input signal to the AEC.
  -The AEC is actually not even turned on in these recordings.
  -The distortions are present even when there is no crosstalk, so I don't think that this is AEC related at all.


To summarize the bullets:
From the above, the only concerning issue I clearly can see in the recordings is the microphone input issue in 5). I need more specific information/recordings to understand what the issues with the rest is.
Furthermore, the findings in 5) indicate a problem in M55 and not in M56/M57 which don't fit with how this issue is described (the description is that there is a regression in M56/M57 compared to M55).

Could you please respond with more information about
a) Even further specific information about what you perceive as regressions in 1)-3) above.
b) A clarification about 4).
c) Further information about 5) such as 
  - whether you perceive a regression in M55 as well?
  - why the aec is off.
  - whether the setups between M53 and M55 differend in any way.

[Re-triage] Per, should we close this?

Yes, I'll close this now.
andsh394@: Please reopen if you still think the issue is valid!