Le mercredi 15 mars 2017 à 12:07 +0100, Alexandre Malingreau a écrit :
> Hi Mr Dufresne,
> I’m a computer science and engineering student (in Belgium) and I’m
> currently writing my master’s thesis on the « Development of a two
> ways speaker communication for home automation. ». The goal is to
> develop (on a linux based) a full-duplex conversation module (like a
> Skype or FaceTime conversation).
> Firstly, I want to thank you for the integration of the webrtcdsp
> module to the gstreamer plugins, I see the huge work you made, it’s
> However, I need some help to finish my experimental work. With my
> current work, the echo is cancelled but at the beginning there is
> more or less 15~20 seconds of side effect where the outputted sound
> looks like a Larsen effect…
The other thing you may try, is to turn on latency agnostic mode in
WebRTC DSP library. See "delay-agnostic" property. You should have a 50
to 200ms adaptation time.
During my integration I never seen such a bad adaptation time. Maybe
the latency reported from your hardware is completely off ? GStreamer
is very far from the hardware, hence is not the best place to implement
the echo cancellation. Whenever you can, use PulseAudio integration
(same library). This is enabled by setting stream-
properties=s,filter.want=echo-cacenl on both pulsesrc and pulsesink. It
won't be portable to other platforms though.
> Do you have any idea or tips in order to suppress this effet ? Maybe
> could I send you some details like the 2 used pipelines to perform
> the communication ?
Ah, maybe you found your bug. Two pipelines ? You need the probe and
the dsp elements to be in the same pipeline (same clock, same base-
time). There is no support for cross-pipeline here.
Le jeudi 16 mars 2017 à 09:19 +0100, Alexandre Malingreau a écrit :
> Indeed I use two pipelines but these pipelines are in the same loop
> (and the shared gst parameters). I don’t see any particular problem
> because the dsp can easily communicate with de probe and cancel the
> echo properly.
It's going to be racy, it will stop working from time to time. Again,
this is not supported and in any case, it should be trivial to use a
single GstPipeline with multiple independent graphs.
> > More details is always better.
> > Nicolas
> My problem is solved, thanks for your response and your help !
> And above all, thanks for the integration to GStreamer !