[PD] Echo supressor.

Fri May 8 17:24:25 CEST 2015

Sorry--I left out this one: xcov-2048

On Thu, May 7, 2015 at 5:11 PM, Charles Z Henry <czhenry at gmail.com> wrote:
> 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 --------------
A non-text attachment was scrubbed...
Name: xcov-2048.pd
Type: application/octet-stream
Size: 2982 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150508/8e6199f8/attachment.obj>