I'm possibly hitting this limitation in my project.

My goal is to analyze the microphone stream obtained with getUserMedia() in it's rawest possible form, *before* all the alterations caused by echoCancellation happen. I need to have the echoCancellation enabled as I'm sending the stream to remote peer via webrtc.

At this point, I'm either able to perform the stream analysis or have a quality call with the remote peer without any echo. I can't have both at the same time.

What I tried so far:

1) initiate two streams via getUserMedia to run side-by-side:
stream1 = mediaDevices.getUserMedia({audio: {mandatory:[{echoCancellation: false}]}});
stream2 = mediaDevices.getUserMedia({audio: {mandatory:[{echoCancellation: true}]}});

Result: the first applied echoCancellation option gets applied to the second stream. Second stream ignores the mandatory echoCancellation preference silently.


2) Cloning an existing stream and calling applyConstraints() on the clone

stream1 = mediaDevices.getUserMedia({audio: {mandatory:[{echoCancellation: false}]}});
stream2 = stream1.clone();
stream2.applyConstraints({mandatory:[{echoCancellation: true}]});

Result: stream2 audio track getConstraints() shows echoCancellation true, but getSettings() shows false. Constraint wasn't really applied


3) Instead of clone, passing stream1 through web audio api to "clone" into stream2

Result: same as above


I wanted to isolate the issue and simply tried to change the echoCancellation on the existing stream1 at any given time, but it wouldn't be applied either. As long as you call getUserMedia to get mic audio, you can't change that in any way since then.

A few question from here:
- Is my problem related to this issue?
- If so, is there any workaround the could help me move forward?

Thanks.

#1, your scenario looks like a bug related to this issue.