WebRTC and AudioContext - poor quality

[Richard Screene]

What I am doing is this:
1) Download a .wav file from the server.  The .wav file is 16-bit mono 48Khz.
2) Create an audio context from the .wav file
3) Create a audio-only WebRTC PeerConnection (using JsSIP) and use the audio context stream as input to the WebRTC stream (rather than using getUserMedia)
4) The WebRTC call is echoed by the FreeSWITCH at the remote end so that all RTP packets received by the FreeSWITCH are sent back to browser wihout any intervention.
5) The WebRTC audio stream received at the browser is played through the speakers.

Most of the time the stream heard is a very good representation of the .wav file but about 25% of the time the audio sounds like its been recorded underwater.  It is the reason for this poor quality audio that I'm trying to track down.

I've tried this on Chrome Canary 34.0.1767.0 on MacOS 10.7.5 and 10.6.8.  I still get poor quality audio when the FreeSWITCH is running on a VM within the same physical machine on which the browser is running so I'm guessing its not a network thing.  There is nothing incriminating in the Chrome log. A Wireshark trace of the RTP packets shows that the number of packets sent and received are similar.

Before I continue trying to isolate this problem can anyone tell me if combining AudioContext and WebRTC in this way is supported?  Is there anything obvious that I've missed?

[Benjamin Schwartz]

Yes, connecting a MediaStream from AudioContext to RTCPeerConnection is supported in Chrome.

The "underwater" audio quality you describe could be related to echo cancellation on loopback inputs.  When echo cancellation is active, and the peerconnection's own input audio is being returned by the other side, very strange things happen (mathematically, this corresponds to a negative echo delay).  See http://crbug.com/256645, http://crbug.com/300102, and https://src.chromium.org/viewvc/chrome?revision=207224&view=revision.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Richard Screene]

Thanks for your quick reply Benjamin.

Presumably I can simply set googEchoCancellation to false in the RTCPeerConnection media constraints to disable the echo cancellation?  I'll try it out when I've solved this other problem!

[Richard Screene]

OK - I've modified my code to set the optional parameter googEchoCancellation to false in the RTCPeerConnection addStream() call when I add the Audio Context stream to the PC.  But, the audio is still sounding occasionally bad.

Am I doing the right thing?  Is there anyway to tell if the echo cancellation is actually disabled (chrome://webrtc-internals seems to show the same information whether echo cancellation has been disabled or not).

[Richard Screene]

I'm seeing the following entries in the Chrome debug log which makes me think I'm doing it wrong:
[0106/120457:VERBOSE3:webrtcvoiceengine.cc(744)] Applying audio options: AudioOptions {aec: true, agc: true, ns: true, hf: true, experimental_agc: true, experimental_aec: true, }
[0106/120457:VERBOSE4:webrtcvoiceengine.cc(760)] Echo control set to 1 with mode 2

[Vikas]

Hi,

I think that the constraint googEchoCancellation is a GetUserMedia constraint. 

/Vikas

[Benjamin Schwartz]

Constraints on addStream are currently ignored by Chrome.  The interaction of GetUserMedia constraints and WebAudio-sourced MediaStreams in Chrome is currently somewhat counterintuitive, and still diverges from the W3C specification in some ways.  I don't know if it's currently possible to disable AEC on WebAudio-sourced MediaStreams.  If it is possible, it may require calling GetUserMedia with AEC disabled, and passing that stream to RTCPeerConnection, in order to set a global AEC-disabled flag.

In the long term we expect to have a more intuitive behavior in this area.

[Richard Screene]

Thanks for your help guys!!  I think I'll delay implementing this feature until the standards catch up.

[Jozsef Vass]

Hi Richard,

We are experiencing something very similar. Please see https://code.google.com/p/webrtc/issues/detail?id=2768. 

Jozsef

On Fri, Jan 3, 2014 at 8:46 AM, Richard Screene <rscr...@gmail.com> wrote: