[PD] Echo supressor.

Fri May 8 00:11:40 CEST 2015

Hi Mario,

I know how to solve this problem, but I'm only part-way there.  I have a
similar problem, rejecting feedback when processing acoustic instruments.
I'm sorry I didn't post what I've got sooner--it needs some more work.  I
can't really tell if I'll be finished with a decent patch soon.

I'm almost through with the derivation in high-level symbolic math, so you
can follow along with the patch and work on it too.

See the latency tester first.  It plays noise from to [dac~] and pics up
the signal from [adc~].  If you want to get a really clean graph for
measuring your system latency, do a loopback test with the cable running
from output to input on your audio interface.  It should run reasonably
well over loudspeakers and will tell you the round trip latency.  There are
two sliders where you can adjust delay to the input (mic) signal or the
output (speaker) signal.

Next, there's the spectrum analyzer patch.  Open the spect-2048_test.pd
patch, then right click on [spect-2048] and open it.  This solves the
spectrum analysis problem on block size 2048.  The result is just written
to some tables in [spect-2048], for you to visually see it.

When it's set to run on block size 16384, it needs to have about 90-100 ms
of latency (don't even try opening it, without the audio buffer length
turned up).

Once you've captured an impulse with the spectrum analyzer as it is now,
you'd have to save the impulse to a file and then re-open with your runtime
patch (and lower latency settings).  The patch spect-16384_test.pd patch
does a better job of calculating the impulse response than the 2048 block
size patch.

I'd like to have reduced latency to run the spectrum analyzer patch with
larger block sizes (for which I need a different [xcov~] that works well on
overlapped block sizes).  The syntax of [xcov~] is already so ugly and will
get worse with overlapped blocks.

Also, the spectrum analyzer math needs a little work.  More to come...

Chuck

On May 7, 2015 7:15 AM, "Mario Mey" <mariomey at gmail.com> wrote:

>  Yes, as I said in the mail, not only the the time of the delay is very
> very short that it would be very difficult for me to find "at hand", also,
> as you say, this time would be variable. My system don't work... I knew it.
>
> I took a look to some pages (*), but I only understand... the title of the
> mails and the PDF filename. The texts are chinese for me. I didn't know
> that echo cancellation is, as Peter Parker said, "quite a substantial
> topic"... and it is out of my hands to try different EC systems. No time,
> no knowledge, no time... no time.
>
> Also, there's http://grh.mur.at/software/adaptive.html... but I don't
> know how to test it.
>
> I made a diagram of my system... if anyone knows which echo cancellation
> system would work for me... I would reallly appreciate it.
>
> Thank you.
>
> (*)
> http://comments.gmane.org/gmane.comp.multimedia.puredata.general/63658
>
> https://ccrma.stanford.edu/~eberdahl/Projects/FeedbackCancellation/FeedbackCancellation.pdf
> Peter Parker sent me this link, but I have to pay to see it:
> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1146062.
>
> El 04/05/15 a las 13:48, Spencer Russell escibió:
>
> You're not likely to get very good results with just a single delay. The
> way these systems normally work (e.g. on phones and conferencing
> systems) is to continuously estimate the transfer function between the
> speaker and the microphone (impulse response in the time domain). Then
> you take the received signal, convolve it with the inverse of the
> impulse response, and mix it into the signal you receive from the
> microphone.
>
> The diagram at the bottom of this page[1] is a pretty good one to
> understand what's going on.
>
> -s
> http://www.speex.org/docs/manual/speex-manual/node4.html
>
>
>
> On Mon, May 4, 2015, at 10:18 AM, Mario Mey wrote:
>
> Hi, there. 2 years ago, I created this thread on the forum:
> http://forum.pdpatchrepo.info/topic/7340/echo-supressor. After talking
> about dBs, I thought I acchived what I was looking for. But no. Nor close.
>
>  My last non-replied post on september 2014 says:
>
>
> *Bringing back to life an old thread... I tried to make this patch work
> LIVE... and it is not as thought.*
>
> *To make this patch work (*1), I should find the perfect delay to suppress
> the audio. Using 44100, the delay time can vary in 0.0226ms. So... it's
> almost impossible to get that. I only acchieve a flanger, nothing else.*
>
> *In the first Patch-Circle done in Argentina last Saturday, I talked with
> Pablo E. Riera about this and he told me about the adaptive external and
> the echo cancellation example... but there is no example like that (only
> intereference cancellation).*
>
> *I will explain again (*2): the operator has a microphone (using one
> channel of input) and it sounds in a LCD (far away) (using one channel of
> output). Above the LCD I have a mic (second channel of input). This mic
> takes what the audience says and send to the operator headphones (second
> channel of output). The operator hears her own voice (with a delay). I want
> to supress this "return". It doesn't matter the latency, I just don't want
> the operator to hear her/him voice.*
>
> *I would need something that learn from the first microphone and get rid
> of what the second mic takes.*
>
> *I hope being clear in my explanation. Thanks in advace.*
>
>
>  (*1): the patch is in the thread. It does something like this: it takes
> the microphone (channel one), invert the wave (by using [*~ -1]), it uses a
> delayline to synch (because of the latency) and mix with the output. The
> intention is, obviously, suppress the microphone after been listened by the
> second microphone.
>
>
> [adc~]
> | \
> | [delwrite~ echo-supressor-A 1000]
> |
> [delwrite~ echo-supressor-B 1000]
>
>
>
> [Hslider] # to synch. It depends on latency (it would have to be exact,
> here is the problem!)
> |
> [vd~ echo_supressor-A]
> |
> [*~ -1]
> |
> |   [vd~ echo_supressor-B 1]
> |   /
>  [+~]
> |
> [dac~]
> (*2): I just updated the explanation
>
>  How can I acchieve an echo suppresor? Is this possible?
>  If I'm not clear in my explanation, please tell me. Thanks.
>  *_______________________________________________*
>  Pd-list at lists.iem.at mailing list
>  UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
> _______________________________________________Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150507/5d966bdb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: latency-test.pd
Type: application/octet-stream
Size: 2084 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150507/5d966bdb/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spect-2048.pd
Type: application/octet-stream
Size: 3839 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150507/5d966bdb/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spect-2048_test.pd
Type: application/octet-stream
Size: 1284 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150507/5d966bdb/attachment-0009.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spect-16384.pd
Type: application/octet-stream
Size: 3853 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150507/5d966bdb/attachment-0010.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spect-16384_test.pd
Type: application/octet-stream
Size: 1228 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150507/5d966bdb/attachment-0011.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xcov~.pd
Type: application/octet-stream
Size: 2838 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150507/5d966bdb/attachment-0012.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xcov-test.pd
Type: application/octet-stream
Size: 2650 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150507/5d966bdb/attachment-0013.obj>