thomas@

What options are you using when you open the mic with getUserMedia? Perhaps you're deactivating AEC in the option? 

FYI, the activation/deactivation of AEC is out of WebAudio's boundary. WebAudio has no control over it.

Hi, as you said, it is not a problem of web audio. I will try to explain a bit more. 

Unlike firefox, in chrome, we must attach the media stream to an audio tag to be able to get the stream in the web audio api.

While doing this the AEC is not working, even if you specify the good constraints for the getUserMedia.

You have to explicitly play the stream through the Audio tag for the AEC to be working. 

So it seems that playing through the audio tag enables audio output samples to be processed by the AEC, unlike with the web audio API.

Can I provide you some informations to be more explicit ?

> Unlike firefox, in chrome, we must attach the media stream to an audio tag to be able to get the stream in the web audio api.

Are you sure about that (I am too familiar with Web Audio)?

var audioCtx, source;
navigator.mediaDevices.getUserMedia({audio: true}).then(
 function (s)
 {
  audioCtx = new AudioContext();
  source = audioCtx.createMediaStreamSource(s);
 });

Seems to work (source is a media tream source).

Oh sure, it's working with a local media stream. I'm sorry, I forgot to mention that i'm talking about remote ones.

In what way does it not work? Again, I am not too familiar with both of those features (WebRTC and Web Audio), but I created an offer on one tab and fed it to the other tab, added the resulting stream from the peer connection into a media stream source node and I did not get an error or anything (I also did not hear a sound, but that was also true for the local media stream and I probably just do not know how to use it).

Sorry for my lack of experience, I just want to help triage this issue. You can just ignore me until someone more experienced (and a Googler, unlike me :)) comes along and triages this instead.

A repro case in a jsfiddle or whatever would certainly help.

thomas@

So I assume your set up is:

[remote] mic -> getUserMedia -> WebAudio~mediaStreamDestination -> (local)
[local ] (from remote) -> WebAudio~mediaStreamSource -> WebAudio~destination -> (local speaker)

I believe AEC only applies to the local microphone stream, not the remote one. So if your remote stream causes echo, WebAudio cannot apply the automatic cancellation effect because it simply does not have the feature.

My knowledge on WebRTC signal chain can be incorrect and WebRTC people can answer your question.

No problem with triage !

In fact AEC is taking audio samples from the output, analyze them, and tries to remove the corresponding spectrum from the microphone input (very naive explanation). 

My guess is that the problem cames from how chromium is handling remote streams and how it feeds them to WebRTC. But I may be wrong.

+CC Tommi who worked on the other bug and may know something about this.

It sounds to me like there may be some misunderstanding going on. Echo cancellation is specifically for a local mic and local speakers. Can you give us a code example that reproduces the problem?

Yes, and remote streams are rendered on the local speakers.

I can make a basic example, but it will be the same as doing a two client
communication, and rendering audio through web API instead of the common
audio tag.

Ah, I think I understand now.

The AEC associated with the local mic, is not aware of the audio that comes from webaudio. Right?
I need to refresh my memory on where we stand with that functionality, but it might still be the case that webaudio renders audio in a way that bypasses the AEC.

Exactly, sorry if i havn't well explained the problem. If you pinpoint me
to the source code corresponding to the problem, i may be able to help
resolving the issue.

I'm marking the issue as available as I won't have time to work on this myself.

The work that's required is actually significant.  It involves making sure that the audio from the renderer is mixed, that the echo canceler runs at a different layer than it does now.  In some time, this will be easier since work is underway to move the echo canceler to a layer where this will be much easier to accomplish, but as it stands, this is quite complicated to do and very risky as it could introduce latency that the echo canceler might not expect and therefore be more prone to failure.

Are you using a PeerConnection? AEC is currently only enabled for remote audio streams when they come from a PeerConnection. This has been a feature request since 2014. See:

https://bugs.chromium.org/p/chromium/issues/detail?id=422420

Firefox and Safari already enable AEC for all audio streams, and it would be really useful if Chrome could activate the same functionality.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

tommi@

Can we at least triage this? The comment #17 suggests this actually depends on the change in WebRTC side. No?

I also believe this is not platform-specific issue. Please correct me if I am mistaken.

This does not depend on WebRTC changes, only Chromium work is needed. As mentioned above, significant changes are required to support this. It's not platform specific.