AEC bad performances with a Wireless Headset/Speaker/Microphone

[Jean-Hugues Gilbert]

Hello people, i'm working with WebRTC in a custom C++ project to test AEC capabilities, and i have problem with a particular setup : using echo cancellation with wireless headset.
I would like to discuss with you all about that, if somebody is willing to help me :)

Here is the issue i created on the bug tracker to precise what i'm doing, how and my different tests :

***

What steps will reproduce the problem?

1. Setup a wireless device (speaker and/or microphone) on your computer

2. Make a project to use AudioProcessing class (and his EchoCancellation capability)

===

3.(Case 1) AudioProcessing class initialized with webrtc::Config setted with :

- new EchoCanceller3(true)

- new DelayAgnostic(true)

Delay are given to echo_cancellation component (apm->set_stream_delay_ms()), calculated with soundcard stream position (work with wired headset)

// OR

3.(Case 2) AudioProcessing class initialized with webrtc::Config setted with :

- new EchoCanceller3(true)

- new DelayAgnostic(false)

Delay are given to echo_cancellation component (apm->set_stream_delay_ms()), calculated with soundcard stream position (work with wired headset)

===

4. AEC level is set to High and is enabled

5. Try to provoke echo, and check if echo cancelation is cancelling echo.

What is the expected result?

> There is no echo in output of AudioProcessing module.

What do you see instead?

> There is still echo, less than no processing, but still some (enough to disturb) 

> Most common behavior is that for 2/3 secondes, echo is partially cancelled, after 5 seconds, there is no echo cancellation at all.

What version of the product are you using? On what operating system?

> WebRTC git clone, builded with "b1963b403f8e9258c35a02d2622da254cbb90c51" revision, used in custom project

> Windows 10 x64

> Wireless Headset : Asus HS-W1

***

I'm aware that wireless headset include more latency in the delay given to echo_cancellation module, and it should be calculated when i'm not using DelayAgnostic configuration (but i don't know how, and i'm not sure it's even possible, ideas ?).

But DelayAgnostic configuration should predict delay for what i understood, even with a wireless headset, but it's not.

I also tried without new EchoCanceller3(true), same result. I can only make it work correctly with wired headsets (through calculated latency).

Is WebRTC AEC is even designed to work with wireless headset ?

Thanks for your time !

[Christoffer Jansson]

Hi,

I see a few potential issues here:

1. The delay reported by the headset sound card could be wrong.
   
2. The headset has it's own processing which could alter the signal thus making it impossible for the AEC to find a match.
   
3. The delay to transfer to headset from it's USB soundcard/transmitter causes issues.

Have you tried enabling the delayAgnostic AEC?

Have you tried a different headset with perhaps less processing done in it?

/Chris

--

---
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6ba4a870-ee51-472e-b11f-92191273f9a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

/Chris

[Jean-Hugues Gilbert]

Thanks for your response Chris. I'm glad someone is disposed to help me :)

First of all, i tried Chrome's webrtc capability to test my wireless headset. I checked in Chrome that WebRTC is enabled, i started a call with "apprtc.appspot.com" and tried to produce echo on my wireless headset, the result was very good, echo was correctly cancelled. So it's no longer a WebRTC bug in my mind.

So, there is a problem in my implementation. You can find my implementation of AudioProcessing class here : http://pastebin.com/gheWVYVS

To sum up, Microphone frames comes to :

ProcessStream(ShFLVDataFrame_Internal frame, ShFLVDataFrame_Internal& out_frame)

Speaker frames comes to :

ReverseStream(ShFLVDataFrame_Internal frame)

Basically, i test with this configuration in C# test project (my implementation of WebRTC is in C++, and used in my program through a C# wrapper of this implementation) :

FLV_FilterConfig config = new FLV_FilterConfig() {
                       acousticEchoCancellation = true, // apm->echo_cancellation()->Enable(true)
                       echoCancellationLevel = FLV_Stream.EnumFilterLevel.HIGH,  // apm->echo_cancellation()->set_suppression_level(HIGH)
                       noiseSuppression = true, // apm->noise_suppression()->Enable(true);
                       noiseSuppressionLevel = FLV_Stream.EnumFilterLevel.VERY_HIGH, // apm->noise_suppression()->set_level(VERY_HIGH);
 
                       noDelay = true, // Activation of DelayAgnostic AEC (see line 438 of my pastebin for impl) 
                       aecVersion3 = true, // Activate AEC v3 (see line 192 of my pastebin)
                       refinedAdaptiveFilter = true, // Activate refinedAdaptiveFilter (see line 193 of my pastebin)
                       intelligibilityEnhancement = true // Activated intelligibility filter (see line 462 of my pastebin)
};

The delay i give to AudioProcessing object with 

apm->set_stream_delay_ms(static_cast<int>(d.GetDelay()));

(line 560)

Delay is calculated in C# implementation, it's directly based on an old Chromium code designed for WaveIn/WaveOut WinMM Audio api. Work very well with wired devices. (see code here : http://pastebin.com/j5TAFwDL)

I thinked of what i did wrong. I here are the few hint i found :
- Maybe giving delay to AEC when DelayAgnostic is enabled is bad ? I remind that i read in a header class that it's not affect it, but maybe it changed ?

- ClockDrifting is maybe influencing too much AEC delayAgnostic ?
- WinMM is no longer adapted to performant AEC process (too big delay ?), maybe using CoreAudio will resolve my problem ?
- Maybe enabling ExtendedFilter to give more space to AEC ?

I'm sorry for digging in so deep and so fast, with my relatively bad english, i hope i was clear :)
 
--

And to answer you Chris, in respective order :
- The delay reported is surely wrong, but for wireless device only. Because of delay added for wireless transfer, the calculation isn't took into account. And i don't think it's even possible... How the usb device could give me this delay ? With which generic api ? :/ DelayAgnostic seems to be the only solution.
- I checked that, there is not. Test with Chrome validated that :) Wireless headset is working.
- Yeah, it's a good supposition. WinMM is maybe too old and delay is too long. ExtendedFilter can correct that maybe ?
- Yes i tested with delayAgnotisc AEC as you read before :)
- I don't have any wireless device, but it is working with Chrome.

Thanks again !