Issue metadata
Sign in to add a comment
|
Web Audio can not initialize echo cancellation
Reported by
ja...@onsip.com,
Apr 21 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Have no headset. Laptop speakers and microphone were used for my purposes. 1. Call getUserMedia, asking for audio only. 2. call createMediaStreamSource, using the stream from gUM. This will be named localSrc. 3. call createMediaStreamDestination. This will be called localDest. 4. connect localSrc to localDest. 5. initiate a webRTC call (for my purposes I use SIP.js). 6. Upon the call completing, create another MediaStreamSource using the remoteStream. Call this remoteSrc. 7. create a remoteDest that hooks to an <audio> element, or just use audioContext.dest, and connect the remoteSrc to this. 8. The remote end speaks, and hears very clear echo. What is the expected behavior? The remote end should not hear echo to the extent that it does. Using webrtc-internals, I was able to see that echo cancellation was not activated. The same case, without web audio, echo cancellation activates, and mitigates the echo problem. Also, using headphones, this problem is entirely mitigated. What went wrong? Echo cancellation did not activate, and in this case it was needed. Did this work before? No Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 49.0.2623.112 Channel: stable OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 21.0 r0 I did not attach a file, but here are the files from recording with webrtc-internals: https://drive.google.com/folderview?id=0B27CUjxHf15ud0oxUjU2anZWZEU&usp=sharing There is also a discuss-webrtc topic, but I believe I've gathered enough evidence for the issue: https://groups.google.com/forum/#!topic/discuss-webrtc/NQ0f8MwwegQ Lastly, I understand the example is a little tricky to set up, but I can give someone credentials to test it if necessary with an app in development, I just did not want to post those publicly here.
,
May 13 2016
This is a duplicate of issue 422420 . It's a pretty serious issue...it basically means that getUserMedia on Chrome is useless for anyone who doesn't have a headset.
,
May 24 2016
Where can I see the repro code? Echo cancellation happens at WebRTC layer and WebAudio has nothing to do with it. Without seeing the code, I am not sure how to confirm this.
,
May 25 2016
I've set up a test version of my application and have a test scenario. It takes two users (2 sets of speakers) to be sensical, but the webrtc-internals charts should still relay the absence of echo cancellation if you can't get a hold of a second laptop: 1) User 1: Go to https://app.onsip.com/app/chrome-bug and login using sip address: james@issue605576.onsip.com and password: chromium 2) User 2: Go to https://app.onsip.com/app/call?n=chromeBug&a=james%40issue605576.onsip.com This is a production page that can only call User 1, and can't receive calls. 3) Have User 2 enter a name and press "Voice Call". Then User 1 will ring, and should pick up. 4) At this point User 1 is using web audio. There is... a lot of code, but inspecting (using User 1's window) sessionInitializationService.js starting from line 41 should detail how the stream is collected and passed to webAudio. I can explain more of the code if necessary, but loading User 1 in Firefox version 46 (47 + introduces an issue with video that I haven't guarded against for this demo version) will produce a call with no echo. 5) If User 1 uses our production phone https://app.onsip.com/app/ in Chrome, the call will not have echo. This call will not be using web audio. Please let me know if you encounter any problems. I've run through each step of this test just now to reproduce, so I hope it's enough to verify the bug.
,
May 26 2016
Thank you for providing more feedback. Adding requester "hongchan@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 26 2016
What I meant by the repro code is a minimal code that isolates the issue. Still, I will certainly take a look, but I doubt that we can pinpoint the issue from the entire app.
,
May 26 2016
James, Chrome will only use AEC if the audio if coming from a PeerConnection. I assume when you say "WebAudio" you mean that the output audio is not coming from a PeerConnection, which explains why there is no AEC. In firefox the AEC code applies to any web audio, not just audio coming from a PeerConnection. Issue 422420 is a change request to make Chrome work the same way as firefox, by moving/changing the AEC code so that it applies to all web audio.
,
Jul 25 2016
Per #7, mark this issue as a duplicate. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rsesek@chromium.org
, Apr 21 2016